Як я отримав повну роботу розробника стека без технічного ступеня або досвіду роботи

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

Частина 1: Охоплення кризи квартального життя

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

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

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

Друга річ полягала в тому, що заняття рюкзаками та серфінгом, хоч і були чудовими, але не допомогли мені знайти той “дзвінок”, який я шукав. Єдине розумне, що було зроблено, здавалося класичним методом спроб і помилок.

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

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

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

Я продовжував так близько восьми місяців, виступивши письменником / редактором та бізнес-аналітиком-фрілансером. Але врешті-решт я почав втрачати інтерес до роботи в журналі.

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

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

І я все ще мав ще щось у своєму списку спроб і помилок, щоб перевірити.

Частина 2: Обід, який змінив моє життя

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

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

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

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

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

Але, є й більше.

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

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

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

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

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

І наш обід закінчився тим, що для мене повністю змінив життя. Більш конкретно, три одкровення зробили це так.

  1. Я був вражений, дізнавшись, що вона не має "справжньої" освіти з веб-розробки, яка для мене на той час не відповідала б лише науковому ступеню. Все, що вона знала, вона дізналася на платформах MOOC (Massive Open Online Courses), таких як freeCodeCamp та Codecademy.
  2. Вона сказала мені, що має досвід у галузі фінансів, як і я. Насправді вона кілька років працювала контролером бізнесу, до недавнього часу, коли вона приєдналася до того ж стартапу, що і я, буквально за кілька місяців до того, як стажуючий.
  3. Коли вона показала мені сторінку портфоліо, яку вона створила, маючи лише півроку досвіду кодування, я не повірив. Це було неймовірно.

Цей обід відкрив для мене світ можливостей. Історія Сандри змусила мене голодувати ще.

Тож тижнями я досліджував різні типи шляхів, якими люди йшли, щоб стати розробниками. Я потрапив на всілякі форуми та статті, багато з яких я знайшов саме тут, на Medium.

Наприклад, у щорічному опитуванні розробників Stackoverflow (100 000 опитаних) було зазначено, що лише половина всіх професійних розробників мала ступінь бакалавра, а з цієї половини ціла третина займалася чимось абсолютно не пов’язаним з інформатикою та програмною інженерією.

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

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

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

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

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

Частина 3: Текст, який коштував мені 6000 доларів

Протягом наступних кількох місяців я провів сотні годин на таких онлайн-платформах, як Codecademy та freeCodeCamp. Я навіть придбав передплату на платну платформу Code School.

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

Я навіть не міг сказати вам, в який момент кодування перетворилося з випадкового побічного проекту на мертвий серйозний: "Я буду професійним розробником". Але це було, мабуть, десь тут. Я якраз збирався отримати свій фронт-енд сертифікат від freeCodeCamp, коли відбулася моя наступна подія, що змінила життя.

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

Я кодував на своєму ноутбуці в гуртожитку в Сальвадорі, коли отримав текст від моєї подруги Марі.

"Я отримав роботу!" - сказано

Марі також вчилася кодувати. Я згадав, як вона кількома місяцями раніше розповідала мені про цю школу коду, до якої вона ходила. "Завантажувальний кемпінг кодування".

Тоді я в основному знущався з неї за це - Отже. Ви заплатите 5000 доларів за 12-тижневий курс? І ви не отримуєте за це жодного університетського кредиту? І ви кинули цю програму МВА найвищого рівня для цього? Звучить законно.

І все-таки вона там була. Через чотири місяці Марі офіційно була працевлаштована в одному з цифрових агентств Accenture в якості молодшого розробника. Я був дуже радий за неї, але, звісно, ​​також надзвичайно ревнивий.

Я припинив те, що робив, і зробив деякі розрахунки. Якби я міг дотримуватися свого поточного темпу, кодуючи приблизно 6 годин на день, приблизно 5 днів на тиждень, я б робив 30 годин на тиждень. Тож, щоб закінчити повну програму на 1200 годин freeCodeCamp, мені знадобиться ще принаймні 8 місяців. І це якби я міг встигати. Що я точно не зміг, оскільки мої гроші закінчувались, і мені довелось би скоро повернутися до Швеції та влаштуватися на нову роботу.

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

Повернемося до старого доброго дослідження Google.

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

Пізніше щорічне опитування розробників Stackoverflow знову заспокоїло мене статистикою, що 88,1% випускників кодування bootcamp були найняті протягом року після закінчення bootcamp.

Завдяки Switchup і Coursereport, це не зайняло багато часу, поки я не відкрив Le Wagon, французьку історію успіху стартапу з кодування bootcamp з більш ніж 15 локаціями по всьому світу і 5 найкращими рейтингами в обох рейтингах (на момент написання статті, фактично # 1 на обох, з 27 місць!).

Порівнявши його з такими альтернативами, як Hack Reactor, Ironhack, General Assembly та NYCDA, кілька основних причин змусили мене віддати перевагу йому над іншими:

  • Відносно низька ціна (тоді 6000 доларів).
  • Орієнтація на підприємництво та розвиток продукту.
  • Глобальна присутність та спільнота.

Тим не менше, я все ще мав кілька сумнівів щодо програми.

  1. Вибір бекенд-мови Ruby та MVC framework Rails. Хоча це здавалося досить поширеним явищем серед інших визнаних завантажувальних таборів, майже кожна стаття, яку я прочитала на цю тему, припускала, що Javascript був справді гарячим і що шукали роботодавці. Наприклад, завантажувальний кемпінг моєї подруги Марі навчав стеку бекенда на основі Node.js та Express.js. Обидві технології на основі Javascript. Деякі загальні аргументи здавалися такими, що Ruby - чудова мова для навчання, але що Node та Express - це навички, які роботодавці оцінюють набагато вище. Чи справді Рубі був конем, на якого можна було зробити ставку?
  2. Тривалість 9-тижневого курсу здавалася трохи короткою. Більшість конкуруючих програм, здавалося, складали щонайменше 12 тижнів, що вже здавалося занадто коротким, щоб стати веб-розробником.
  3. Le Wagon не запропонував жодної фактичної допомоги у пошуку роботи після завершення завантажувального табору. Багато конкурентів пропонували або гарантії працевлаштування, або, здавалося б, надійні функції кар'єрного обслуговування.

Кожен із цих трьох сумнівів я розгляну по черзі своїми висновками після завантаження в кінці наступного розділу.

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

Підключившись до безглуздого Wi-Fi у кафе у ледачому серфінгові Ель-Тунко, ми коротко поспілкувались. Але це було набагато неформальніше, ніж я очікував. Я відчував, що ми зв’язані, що викликало у мене бажання ще більше прийняти. А потім, навіть через 24 години, я отримав електронний лист, якого чекав. Гас сказав мені, що буде радий взяти мене в наступній партії, і що єдине, що мені потрібно було зробити далі, - це сплатити депозит в 1200 доларів, щоб зарезервувати своє місце.

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

Отже, після короткої хвилі вагань і, згадуючи проблеми, які я все ще дотримувався щодо Ле-Вагона, я діяв на інтуїцію і передав Гасу депозит. Згодом, пам’ятаю, я почувався трохи незручно. Чи я справді зобов’язався заплатити майже 6000 доларів за 9-тижневий курс кодування? Як швед, який ніколи ніколи не платив жодного копійки за освіту, ситуація виглядала досить химерною.

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

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

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

Фу! Лише тижнем тому я був мандрівником-втікачем, не думаючи ніколи повернутися додому. Тепер я мав розпочати свій новий двомісячний концерт у Стокгольмі менш ніж за два тижні, а потім переїхати до Барселони. Дійсно захоплюючі речі.

Частина 4: Bootcamp у Барселоні

Перемотування вперед за три місяці .. Це 1 травня 2017 року, і я перебуваю в класі, відвідуючи свою першу лекцію в Le Wagon.

Навколо мене близько 25 людей з усіх куточків світу. Кіліан з Німеччини, Даніель з Венесуели, Франческа з Франції, Арбі з Італії, Кортні з США тощо. Хтось взагалі не має досвіду кодування, хтось трохи, а хтось насправді на півдорозі до отримання ступеня інформатики.

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

Як ми всі приходили вчитися, графік був дуже систематичним. Протягом найближчих 9 тижнів ми витрачали б більш-менш однакову кількість часу на 6 різних модулів, кожен з яких займався власною темою, закінчуючи двома тижнями, витраченими на планування та розробку нашого власного веб-додатку.

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

Незважаючи на те, що Рубі був для мене ще досить новим, основи, здавалося, були майже такими ж, як і з Javascript та Python. Прослуховування лекцій та виконання вправ для вивчення змінних, масивів, хешів, основних функцій та ітерацій відчували себе досить повторюваними. Тож я став сором’язливим і подумав, чи дійсно я щось вийму з цього буткемпу. Однак навіть через тиждень все це зміниться. Я перейшов від почуття, як на вершині класу, до того, що насправді намагався не відставати.

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

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

Іншим джерелом розчарування був розрізнений характер речей, які ми вчились. Здавалося, нам дали сотню частин головоломки, але жодних вказівок, як їх скласти. Знання того, як писати базовий Ruby, HTML, CSS, Javascript та SQL, справді розширювало можливості, але як би ці знання допомогли мені скласти реальний додаток?

І ось настав мій великий момент AHA.

Це був тиждень 6, і ми нарешті дійшли до модуля Ruby on Rails. До того, як я це зрозумів, я дивився у вікно свого браузера Chrome і читав слова “Ага! Ви на Рейках! ”. Це була моя перша веб-програма, сказала вчителька.

Що? Все, що я зробив, - це запустити кілька простих команд у своєму терміналі та перейти до // localhost: 3000 / у моєму браузері. На що я взагалі дивився?

Лише коли я не відкрив каталог програм у текстовому редакторі, це велике миле розуміння стало на своє місце. Рейки відображали все це так красиво просто.

Одна папка для HTML, одна для CSS і Javascript, одна для контролерів і одна для моделей. Один файл для маршрутів. І один файл для цієї солодкої, солодкої схеми, що відображає всю базу даних, ніби вона не була більш складною, ніж список покупок у продуктових магазинах.

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

Я ходив по черзі, отримуючи нові знайомства щодня. І це дало цей сп’янілий ефект, який досі важко передати словами.

  • Тож я дійсно можу змішувати HTML та Ruby у своїх файлах erb?
  • Я можу отримати доступ до змінних екземпляра з контролера у відповідному файлі html.erb?
  • Я можу імпортувати код, який писали інші люди, використовуючи цю штуку під назвою Gems?
  • Я можу написати стільки ванільного JavaScript, скільки хочу, в каталог assets / javascript?
  • Я можу використовувати консоль Rails у терміналі, щоб в основному робити все, що хочу, з усією базою даних?

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

Так чи інакше, поїзд bootcamp не гальмував, і досить скоро ми досягли останніх двох тижнів, коли ми мали створити власний додаток. Два тижні закінчувалися великим демонстраційним днем, коли кожна група представляла та демонструвала свої програми перед камерами та великою аудиторією.

Тиск.

На наш подив, планування виявилося найбільш трудомісткою частиною на сьогодні. Хоча за останні кілька тижнів ми багато підготувались - пропонували ідеї додатків, формували групи, розробляли функції у Sketch - лише через кілька днів кодування ми зрозуміли, що були занадто амбітні.

Початковою ідеєю програми було щось на зразок “Happn для професійних зв’язків”. Більш конкретно, дозволяючи користувачам створювати сторінки для мережевих подій, на які інші користувачі могли б відвідувати та реєструватися. "Але це Meetup", - можливо ви думаєте. Але наша ідея мала поворот: ви можете зареєструватися на подію, лише якщо ви фізично знаходились у місці події. Таким чином, “Happn для професійних зв’язків”.

Після реєстрації на заході користувач зможе побачити професійні профілі інших зареєстрованих користувачів, використовуючи дані, зібрані через API LinkedIn, і зв’язатися та поспілкуватися з тими, хто відповідає їхнім інтересам, таким чином не втрачаючи потенційно чудових зв’язків .

Це був наш початковий MVP (мінімальний життєздатний продукт), і ми вирішили назвати його Unify. Супер банально і хочеться Силіконової долини, я знаю. Але на наш захист нам було зручніше з часом, ніж думати про кращі імена.

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

  1. ніколи не буде готовим до демонстрації протягом решти десяти днів, і
  2. не був настільки руйнівним, як ми думали, наша перша ідея.

Тож нам довелося звузити особливості до MVP, і насправді ми отримали майже такий самий продукт, з яким з самого початку рекомендував нам менеджер Le Wagon.

Тоді ми думали про велику втрату часу. Але процес принаймні навчив мене кільком справді важливим речам щодо розробки продукту:

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

Приблизно через десять днів, після більш ніж 100 годин кодування, проектування, аргументування, тестування, міграції баз даних та відкотів бази даних, ми якось дивом досягли Дня демонстрації і насправді почувались досить добре з нашим додатком. Звичайно, це було далеко не ідеально, але всі основні функції насправді працювали так, як ми цього хотіли.

Однак лише за кілька годин до демонстрації у всіх нас ледве не стався серцевий напад.

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

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

Але він запізнився, тому ми спробували зателефонувати йому.

Без відповіді.

Ми спробували зателефонувати ще раз.

Відповіді знову немає.

А потім ми запанікували.

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

І вуаля - додаток працював ідеально. І демо-версія теж.

Загалом , мій досвід Le Wagon був нічим іншим не вражаючим. Я, мабуть, ще ніколи не дізнався так багато за такий короткий час. З огляду на минуле, насправді важко повірити, що більшість з нас змогли розробити повнофункціональні веб-програми, які в основному мали лише 9 тижнів досвіду розробки.

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

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

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

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

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

І причиною того, чому (хороший) завантажувальний кемп може перетворити вас на розробника швидше, ніж на самонавчання, є поєднання наступного:

  • повна, але коротка навчальна програма,
  • бездоганна онлайн-платформа з підручниками та вправами, а головне;
  • підтримка на виклику людини при ударі об стіну.

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

1. Вивчення Ruby on Rails замість стека на основі JavaScript

Якщо ви зараз перебуваєте в тій позиції, в якій я перебував до приєднання до мого завантажувального табору Rails, пригнічений всім ажіотажем JavaScript, що заполонив Інтернет, ви можете запитати себе, чи Ruby є давно встановленою мовою, і чи Rails є застарілою структурою. Якщо це так, моя коротка відповідь буде ні.

Однак довгою відповіддю буде така.

Зараз у компанії, в якій я працюю, є веб-додаток із великим трафіком, побудований із Rails на серверній панелі та фронтенд-рамкою Ember.js на передній панелі. Працюючи з цією програмою повний робочий день близько півроку, від мене потрібно було стільки ж кодування в Javascript, скільки в Ruby, що принесло мені певне розуміння відмінностей та подібностей між технологіями.

І, звичайно, коли мова заходить про візуалізацію HTML / CSS на стороні клієнта (або “подання”), користувальницька робота Rails навіть не порівнянна з великими фреймворками JavaScript. Що я повинен дати Rails ненависників.

Наприклад, візьміть основний розділ коментарів статті чи публікації в блозі. Як користувач, ви очікуєте, що будь-які надіслані вами коментарі миттєво з’являться на екрані.

У сучасній структурі JavaScript це просто питання виштовхування нових даних (коментаря) у сховище даних на стороні клієнта та забезпечення того, щоб список коментарів оновлював свій стан, щоб показати новий коментар. Таким чином, вам не потрібно чекати, поки новий запис буде надісланий повністю до серверної бази, збережений у базі даних, а потім знову запитаний клієнтом. Натомість новий коментар миттєво з’являється на вашому екрані.

Без будь-якого JavaScript поверх вашого коду Rails HTML, користувачеві доведеться оновити сторінку, щоб побачити будь-які нові коментарі до статті. Що просто жахливий UX. Щоб уникнути цього, ви можете піти кількома різними шляхами.

До епохи фреймворків JS головним рішенням було б посипати трохи неструктуровану логіку AJAX поверх HTML-коду, який часто стає дуже важко підтримувати в довгостроковій перспективі, оскільки ваш додаток стає більшим. Ще одним варіантом, доступним для Rails зовсім недавно, є рішення pubsub (публікація-підписка) через веб-розетку, що використовує щось на зразок Action Cable. Наприклад, це те, що ми використовували для чату в програмі, яку ми створили в bootcamp. Проблема полягає лише в тому, що без обгортання фреймворку JavaScript, логіка websocket може легко стати надмірно складною, а також важкою в обслуговуванні.

Однак на щастя, сьогодні ми маємо набагато кращий варіант використовувати фреймворки JavaScript для таких типів проблем. І оскільки клієнтська сторона, на мій погляд, є найслабшим місцем Rails, це також мій головний аргумент, чому Rails не слід відкидати як опцію, наприклад, для Laravel або стеку MERN. Просто вдаривши чіткий фреймворк JavaScript зверху, наприклад React або Ember, і все готово.

Мені особисто подобається наша інтеграція між Rails та Ember та те, як вони доповнюють одне одного. Їх самовпевнені вдачі, солідні результати, прозорливе керівництво та величезні спільноти внесків роблять їх стабільними, надійними та придатними для молодших розробників, як ми.

Якщо ви все ще, незважаючи на мої зусилля, вагаєтесь щодо ставок на Ruby як на вашу першу бекенд-мову, я хотів би нагадати, що я майже нічого не знав про JavaScript півроку тому (за винятком деяких основних ванільних JS, React, і синтаксис jQuery), і сьогодні я щодня працюю з цими двома мовами та фреймворками та переходжу між ними. І любити кожну хвилину цього (образно кажучи).

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

2. Чи не надто мало 9 тижнів, щоб навчитися чомусь?

Що стосується мого занепокоєння тим, що тривалість завантажувального табору - всього 9 тижнів - може бути занадто короткою, щоб насправді дізнатися щось цінне, Le wagon також допоміг мені зруйнувати цей міф. З огляду на минуле, насправді ясно, що я віддаю перевагу 9 тижнів, аніж 12, які пропонує більшість інших завантажувальних таборів.

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

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

Озираючись назад, насправді надзвичайно чудово, наскільки точним був набір інструментів Le Wagon. На своїй нинішній роботі я використовую більшість цих інструментів щодня. Деякі приклади можуть бути Postgres, Git, GitHub, Sidekiq, Pundit, Heroku та Cloudinary. Єдині дві речі, на які я хотів би, щоб мої вчителі витратили більше часу, - це те, як використовувати фреймворк JavaScript, такий як React, і те, як писати тести з такими технологіями, як Rspec. Тому що пізніше вивчення цих двох самостійно виявилося вирішальним для отримання моєї першої роботи розробника.

3. Чи допомогли б мені гарантія роботи та / або кар’єрні послуги?

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

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

Частина 5: Створення портфоліо

В останньому липні минулого літа буткемп закінчився. Але я тільки починав.

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

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

  • Я кодував би кожен день, поки не досяг своєї мети, яка, звичайно, отримала першу роботу розробника. Це означає з понеділка по неділю, день і ніч.
  • Я хотів би підштовхнути кожен фрагмент коду, який я написав до Github , місце №1 для потенційних роботодавців, щоб перевірити ваші навички кодування та рівень амбіцій. Навіть якби я не відчував, що створив щось, що варто зробити, я все одно роблю це лише для того, щоб спиратися на цю солодко-зелену історію комісій, щоб побачити весь світ.
  • І я б повністю занурився у стільки програмного вмісту, скільки міг . Це означало прослуховування таких подкастів, як Software Engineering Daily та SE Radio, коли б я виконував якісь доручення, не працював чи не готував їжу. Це означало перегляд кодових розмов, навчальних посібників та лекцій із таких каналів Youtube, як Coding Tech, Traversy Media та CS50. Це означало читання середніх публікацій, таких як Hacker Noon, freeCodeCamp, Codeburst та журналів, таких як Techcrunch та The Next Web. І це означало встановлення Dash на своєму ноутбуці, щоб завжди легко було знайти відповідну документацію з будь-якої проблеми синтаксису, з якою я боровся в будь-який момент (для мене тоді це переважно веб-документи MDN, api.rubyonrails.org та RubyDocs) .

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

На наступний день після демонстраційного дня, ледве тверезий від наступної ночі, я почав створювати свій перший власний додаток Rails (настільки сильним був цей імпульс!). Як би я не був пихатим, я думав, що перша програма займе кілька тижнів, щоб закінчити, тепер, коли я вже пройшла це все один раз за допомогою програми Unify. Знову ж таки, я помилився.

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

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

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

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

Досить скоро прийшов час для кодування фактичного веб-сайту портфоліо. І раз я вирішив зробити це просто. Тож я склав дуже мінімалістичну статичну веб-сторінку, де міг зібрати зроблене мною.Після його закінчення я планував почати претендувати на роботу. Але щось мене турбувало. Пам’ятаєте, як я сказав, що трохи вагався щодо Рубіна на Рейлах, перш ніж приєднатися до Le Wagon? Ну, хоча я насправді полюбив мінімалізм Рубі та простоту використання Rails, я все одно відчував, що десь скористався ярликом.

У розділі «Навички» на моїй сторінці портфоліо можна знайти Ruby, Rails, SQL, Postgres, HTML / CSS, jQuery, Bootstrap, Sketch, Git та Heroku. І JavaScript.

Це мене останній турбував. Це було схоже на брехню.

Якби я почав претендувати на роботу зараз, я, напевно, міг би отримати щось гідне як розробник Rails. Але що, якби всі ненависники мали рацію, а Рейлс насправді був застарілим і вмирав? А що, якби я знайшов роботу, про яку мрію, лише усвідомивши, що вони використовують передові технології JS? Я не мав би шансів з моїми 200 годинами на freeCodeCamp та 2-3 днями jQuery + 1 днем ​​React.js на завантажувальному таборі.

Надмірна частина мого мозку знову заговорила зі мною - "Ось ідея: а якби я також навчився стеку MEAN?" ЗНАЧІТЬ, як у MongoDB, Express.js, Angular.js та Node.js, що нагадує JavaScript, еквівалентний тому, що Rails - це Ruby. Згідно з результатами пошуку на LinkedIn та Glassdoor, це означало б, що я більш-менш подвоїв кількість робочих місць для розробників, на які я отримав право.

Я згадав, що Гас, менеджер завантажувального табору, сказав мені, що для вивчення цього знадобиться ще близько місяця. Як важко це може бути? Я, мабуть, міг зробити це за два тижні, - така моя думка.

І ось так я опинився у тому, що я хотів би назвати навчальним болотом .

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

Тоді я відкрив абсолютно новий вимір освітніх питань розвитку: навчальні посібники YouTube. Там було так багато там. Для кожної технології або стека, про які я міг подумати, я знайшов щонайменше п’ять гідних підручників.

Врешті-решт я знайшов свій шлях до каналу Traversy Media та навчальної серії MEAN Stack Front To Back. Десять відеозаписів по 20 хвилин, котрі показують, як створити базову веб-програму RESTful з реєстрацією користувачів та аутентифікацією під час входу. Ідеально

Я почав одразу і кодував кожне відео на своєму ноутбуці. І досить божевільний, через кілька днів я закінчив. Я насправді закодував повністю функціонуючу веб-програму, використовуючи абсолютно іноземні технології. Вузол для бекенда, Mongo для керування базою даних, Angular для інтерфейсу та Express для зв’язування всього цього.

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

Ну, оскільки я випередив графік, я зрозумів, чому б не вбудувати додаток трохи далі? Моя ідея полягала в тому, щоб перетворити його на середній клон, просто включивши основні дії CRUD (створення, читання, оновлення, видалення), як це було зроблено в проекті в завантажувальному таборі з Rails.

Однак я не дуже далеко зайшов. Я розрахував, що мені просто потрібно буде додати пару нових маршрутів, моделей, контролерів та переглядів, і все. Проблема полягала в тому, що я все ще розмірковував “Rails way”, де “домовленість щодо конфігурації” робить такі функції справді простими та швидкими в побудові.

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

Тож усвідомити, наскільки важче було кодувати за «конфігурацією за конвенцією», стало великим ляпасом. Тому що це довело, що моє уявлення про те, що весь підручник був занадто гарним, щоб бути правдою, було правильним. Але лише тоді, коли я почав кодувати скрипт, не маючи втішних вказівок Бреда Траверсі, я зрозумів це.

Отже, я опинився там, по глибині коліна у великому басейні бруду, який тоді був для мене СРЕДОМ. Додаток був недалеко готовий до додавання на мою сторінку портфоліо. Він буквально не мав особливостей. Просто можливість для користувачів зареєструватися, увійти в систему та не робити нічого, крім перегляду деяких статичних конструкцій Bootstrap.

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

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

І ось як веб-програма, яка в кінцевому підсумку мала стати клоном середнього класу, стала програмою виявлення музики за допомогою API Spotify Search.

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

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

Частина 6. Подання заявки на роботу

Загалом, мені знадобиться близько 4 тижнів, 30 заявок, 10 інтерв’ю та 3 пропозиції, щоб знайти ідеальну відповідність. І як не дивно, це була б фактично перша компанія, до якої я звернувся, до якої я приєднався б. Звичайно, я міг би назвати це випадковістю, але я думаю, що це скоріше ефект ретельного процесу перевірки перед тим, як почати надсилати заявки.

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

Перше, що я зробив, створив електронну таблицю для короткого списку цікавих робіт (спочатку я нудний економіст, пам’ятаєш?). Потім я кілька днів обшукував дошки вакансій LinkedIn, Glassdoor та Stackoverflow, шукаючи завдання на основі таких ключових слів, як Інтернет, розробка, програмне забезпечення, інтерфейс, серверний сервер, Ruby, Rails, Javascript, Angular, Node та Postgres.

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

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

Якби я міг вибрати будь-яку роботу, яку хотів, мої пріоритети виглядали більш-менш такими:

  1. Я б кодував весь стек, це означає, що я мав би робити стільки ж матеріалів з баз даних та архітектури, скільки UX / UI, і переважно в JavaScript. Весь ажіотаж навколо React, мабуть, багато в чому пов’язаний з останнім. Як я вже казав вам раніше, незважаючи на те, що я знав на цей момент, Rails в основному вмирав, а JavaScript - майбутнє.
  2. Моя крива навчання була б надзвичайно крутою, до того, що мені доводилося б кодувати день і ніч, щоб не відставати. Все стати настільки добрим, наскільки я міг, можливо, за найкоротший проміжок часу.
  3. Мої колеги були б розумними, амбіційними, веселими та неофіційними, і бажано всіма одночасно.
  4. Компанія буде стартапом зі швидким зростанням зі значущою місією та продуктом, пов’язаним із блокчейном, ШІ та / або стабільністю, або цифровим агентством вищого рівня з такими проектами.
  5. Мені б чесно заплатили.

Це було про це. Можна подумати про досить високі вимоги до новачка. Але зверніть увагу, що висока зарплата не входила в критерії (як і сьогодні, при 6-місячному професійному досвіді). Можливо, я заявляю очевидне, але якщо ви переходите на чисту роль розвитку з чогось зовсім іншого, я вважаю важливим знати, що не має значення, що вам платили раніше.

Наприклад, я знав, що моя ринкова вартість у фінансовій галузі становить близько 5000 доларів на місяць. Але розуміючи, що розробка програмного забезпечення - це принципово інше ремесло, я поставив перед собою мету близько 3700 доларів, але погодився б на 3000 доларів (що значно нижче середньої зарплати в Швеції близько 4000 доларів).

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

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

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

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

По-друге, я побачив, що чим гарячіша і більша компанія, тим більше шансів включити вимоги до певного ступеня інформатики та досвіду професійного розвитку. Я вважав, що пристойний портфель та супровідний лист, ймовірно, можуть дати вам інтерв’ю з компанією, яка вимагає “Rails ninja” чи “React superstar”, а не новачка, як я.

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

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

Настільки вражений, що я насправді вирішив витрачати кілька годин на день на створення невеликого веб-додатку React, використовуючи React.js спереду та Rails ззаду, щоб я міг додати це до свого портфоліо та також відновити.

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

За винятком того факту, що я міг поставити React у своєму резюме, найбільшою вигодою від цього досвіду було комфортне створення веб-програми з використанням компонентів (на відміну від контролерів та переглядів, як це робить Rails), а також робота з реквізитами та станом .

Швидше за все, вам рано чи пізно доведеться подружитися з якимось фреймворком JavaScript, і тоді ці концепції стануть у нагоді в будь-якому випадку, будь то React, Angular, Vue, Ember або будь-який інший із загальнодоступних фреймворків JavaScript.

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

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

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

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

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

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

Потім я почав отримувати відповіді.

Частина 7: Проведення співбесід

Перша відповідь надійшла від справді молодого стартапу. В основному він складався з двох хлопців, екс-генерального директора банкіра та старшого технічного директора-розробника. Електронний лист надійшов від технічного директора, і він запросив мене на моє найперше інтерв’ю для розробників.

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

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

Хоча я не думав, що компанія насправді відповідає всім моїм критеріям (головним чином через крихітну команду та поганий прогноз зарплати), я негайно відповів і прийняв запрошення.

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

Часто випускники буткемпів та кодери-самоучки з більшим практичним досвідом не проходять технічне співбесіду через відсутність знань з фундаментальної теорії інформатики. Так само, як студенти CS часто не справляються через відсутність досвіду у створенні програм за допомогою сучасних технологій.

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

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

Місце було сміттєзвалищем. Якщо ви коли-небудь бачили The Office, здавалося, що я щойно зайшов до офісу паперової компанії Dunder Mifflin. Вони сказали мені, що це колись був офіс для великої аудиторської компанії, перероблений у дешевий тимчасовий коворкінг-простір на час, що залишився до запланованого оновлення. Ми зайшли в конференц-зал і сіли біля великого дерев'яного столу.

Вони почали з того, що розповіли мені багато про себе та компанію. Вони щойно випустили бета-версію нової програми Medium-ish для видатних авторів способу життя та зібрали трохи грошей від друзів та сім'ї у своєму насіннєвому турі. Але вони все ще були до запуску, і, безумовно, до прибутку.

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

Але жоден не прийшов. Натомість технічний директор починає задавати мені всі ці дуже відкриті питання.

Як і те, які технології та рамки мені сподобались. Якби я міг вибрати будь-яку нову технологію для подальшого навчання, якою вона б була. Що я думав про новий синтаксис, представлений ES6 (оновлення Javascript 2015 року, що представляє багато нових цікавих матеріалів, таких як функції стрілок, обіцянки та константи).

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

Він сказав мені, що через їх фінансове становище вони можуть запропонувати мені лише 6-місячну стажування із символічною оплатою (мається на увазі практично відсутність зарплати). Однак, якщо стажування проходило добре, вони були дуже готові запропонувати як справедливість, так і гідну оплату.

"Якщо компанія до цього часу ще працює", - майже додав я.

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

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

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

Непогана ідея. Незважаючи на те, що оголошення про роботу, що починаються такими словами, як "найм" та "HR", 9 днів із 10 мене відлякали б, у цій компанії щось заінтригувало.

З мого досить ретельного дослідження я виявив, що вони існували близько 4 років, мали близько 30 співробітників, були присутніми в 4 або 5 країнах, 600 клієнтів (підприємств), темпи зростання доходу + 100% деякий запас зверху. Зовсім непогано.

До всього іншого, їх акаунт в Instagram показав їх офіс: старий пивний завод з червоної цегли в Брукліні посеред Седермальма, найкращий район, який може запропонувати Стокгольм.

ММ Ммм.

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

У всякому разі. Знову ж таки, мені писав технічний директор. Після кількох повідомлень туди-сюди ми через кілька днів зупинились на першому інтерв’ю в їхньому кабінеті. Мені сказали, що і він, і інший співзасновник зустрінуться зі мною.

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

По-перше, великий рожевий плакат прямо на моєму обличчі, з жирними білими літерами, що кричать на мене: “Teamtailor - один із 100 найгарячіших стартапів Європи - Wired Magazine”. Зліва від мене виглядало як вітальня, де купа 20-ти років грала у ФІФА на величезному екрані. Переді мною більша кімната, де найближчий до мене стіл був наповнений розробниками, випадково зламаними на великих чітких екранах. І навколо мене м'який хіп-хоп пульсує від динаміків Sonos.

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

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

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

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

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

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

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

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

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

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

Розмова тривала настільки гладко, що лише останні кілька хвилин вони запитали мене про моє портфоліо. Лише один із них насправді дивився на це, і він буквально сказав, що просто "подивився". Всім зрозумілий, наскільки добре пройшло інтерв’ю, я сказав їм, що із задоволенням демонструю один із своїх додатків.

Одразу їх обличчя засвітились, і вони випрямились на стільцях, кивнувши мені. Я збирався зрозуміти, що щойно припустився ВЕЛИКОЇ помилки.

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

Перше збентеження полягало в тому, що завантаження домашньої сторінки займало буквально 20 секунд. Засихаючи в горлі, я намагався пояснити, що використовую безкоштовну версію Heroku, що означало, що всякий раз, коли сервер, пов’язаний з доменом, не отримував запитів більше години, він переходив у цей „сплячий режим”. від якого довго прокидалося. Останнє, що я хотів, - вони думали, що мій додаток працює повільно.

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

Потім настало друге збентеження. Коли я спробував увійти в свій обліковий запис за допомогою автентифікації Facebook, це не вдалося. Оскільки я зрозумів би занадто пізно, причиною було те, що я не оновлював URL-адресу у налаштуваннях Facebook API після отримання нового сертифіката SSL. Тож Facebook очікував запитів з // домену, тоді як мій надходив з // домену. Помилка новачка.

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

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

Ми попрощалися, і вони сказали мені, що будуть на зв'язку. Я пішов з інтерв’ю з почуттям гніву та розчарування. Чому я не підготувався до демонстрації краще? До останньої частини все проходило так гладко.

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

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

Основною метою було б зрозуміти, наскільки добре я знав їх серверну структуру (Rails), і наскільки швидко я міг би вивчити їх фронтенд-фреймворк Ember.js (про який я навіть не чув на даний момент).

Я відразу зрозумів, що демонстраційний додаток повинен бути тим, який я створив за допомогою Rails та React.js. Це було ідеально з двох причин:

  1. він побудований на Rails, інтегрованому з фреймворком JavaScript (як і їх стек), і
  2. Я вивчив усі речі React, якими користувався менш ніж за два тижні, що дало б їм зрозуміти, як швидко я можу навчитися Ember.

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

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

Я зайнявся веб-додатком, і досить швидко робоча назва «AppHunt» засвітилася на екрані великими жирними фіолетовими літерами. Це було щось на зразок полювання на продукт, але більше схоже на ринок, призначений виключно для програм. Тож будь-який користувач міг би переглядати домашню сторінку програм, що продаються та купуються. А якщо вони створять обліковий запис і увійдуть в систему, вони також зможуть шукати та фільтрувати елементи програми, оцінювати їх та писати матеріали у полях коментарів. Це було в основному це.

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

  • Те, що функції в режимі реального часу, такі як зміни в коментарях, результатах пошуку та рейтингах, що з’являються миттєво, показали, що я знав, як користуватися станом та реквізитами, що є ключовим у будь-якій структурі JavaScript.
  • Те, що я використовував JBuilder для серіалізації запитів JSON між інтерфейсом та серверною базою.
  • Те, що я використовував Elasticsearch для функції пошуку.
  • Те, що їм сподобався дизайн, і що я сам зробив свої ескізи в Sketch, перш ніж починати кодування.
  • Те, що код CSS не був дуже контекстуально стильований або вкладений. Натомість вони знайшли багато чого для багаторазового використання протягом усього додатка, що було добре. Одна річ, яка могла б зробити їх ще більш враженими, хоча, як вони сказали мені, це було б, якби я також дотримувався так званої конвенції про іменування BEM CSS.

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

Я прийняв на місці і розпочав нову роботу наступного тижня. ✌️

Паралельно з усім процесом Teamtailor я брав інтерв'ю ще для 4 компаній. Найбільш вартим уваги був шведський фінтех-феномен iZettle, який є свого роду парасолькою декількох різних фінансових продуктів, але там, де їхній бездротовий термінал, мабуть, є тим, яким вони найбільш відомі.

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

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

Так само, як і в інших компаніях, перше інтерв’ю стосувалося пуху та м’яких навичок. Але ще більше “HR” цього разу. Чому ви хочете працювати розробником? Які технології ви любите використовувати? Які ваші сильні / слабкі сторони? І так далі. Легкі речі.

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

З нізвідки хлопець за столом подав мені величезний білий папір формату А3 та ручку. Він сказав мені, що вони хочуть, щоб я намалював ескіз потоків даних та процесів, задіяних у наступному сценарії:

“Власник малого бізнесу має рахунок у iZettle і використовує термінал їх карт. Після того, як один із його власних клієнтів здійснив покупку за допомогою терміналу, він / вона хоче увійти у веб-програму та / або мобільну програму, щоб побачити транзакцію ».

Це справді застало мене зненацька, але я нерішуче кивнув і прийняв виклик. Потім хлопець сказав щось на кшталт: "Ми просто підемо випити кави, а потім приблизно через 5 хвилин повернемося і дамо вам пояснити свої думки".

5 хвилин! Це був жарт? Я справді не міг сказати. Коли вони пішли, я серйозно задумався, чи це якесь хитромудре питання, де я мав зрозуміти, що це завдання було просто занадто великим, щоб його можна було гідно виконати за такий короткий час. Але час уже йшов, і це було занадто великим ризиком. Тож я вирішив спробувати.

Оглянувшись назад, я усвідомлюю, що це було питання дизайну системи, тобто, вони хотіли, щоб я в основному просто склав загальний огляд того, як веб-програма та мобільний додаток робили запити на якийсь API, який зв’язував їх із серверами та базами даних (якщо ви хочете вдосконалити свої навички проектування системи, я справді рекомендую цей канал Youtube).

Але я нічого з цього не зробив. У моєму стані паніки я пропустив кілька кроків і почав намагатися намалювати модель бази даних облікового запису користувача з таблицею, стовпцями та зовнішніми ключами (я припускав, що вони використовують реляційну базу даних). Коли я закінчив із цим, у мене залишилося близько 30 секунд, щоб відобразити інші компоненти архітектури. Я був настільки підкреслений, що зрозумів усе філософське і почав ставити під сумнів фактичну роль API та сервера. Не хороший знак.

Минуло 5 хвилин, і двоє розробників повернулися до ескізу, ледве гідного 5-річного віку. Я в основному просто намалював три кола. Один ліворуч, що представляє базу даних, а два праворуч, що представляє клієнтів Інтернету та мобільних додатків.

Звичайно, я провалив інтерв’ю з жалем. Що також було причиною того, що я не перейшов до третього. Однак вони мене легко підвели, сказавши, що я їм сподобався і що я маю подати заявку ще раз, коли маю ще один-два роки досвіду.

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

Загалом , протягом 4 тижнів пошуку роботи я в підсумку відвідав 11 співбесід для 6 компаній, з яких 3 зробили мені пропозиції. Тож, незважаючи на те, що спалився кілька разів, це був справді дивовижний досвід. Якби мене попросили назвати єдину найбільшу винагороду (за винятком отримання пропозиції, про яку я мрію), це було б, щоб мені було зручно поговорити з розробниками про програмне забезпечення . Якщо ви страждаєте на синдром самозванця, як я (подивіться, це річ), просто немає кращого способу його лікування.

Ще одним ключовим висновком є ​​те, що з моїх 11 інтерв’ю лише одне виявилося, що вимагає реальних теоретичних знань з інформатики. Жодних питань щодо складних структур даних, ніяких хитроумних мозку. Лише одне питання про архітектуру системи. Решта були на 100% зосереджені на практичних або м’яких навичках. Тож якщо ви не подаєте заявку на кричущу роботу в інженерії програмного забезпечення в Google чи Facebook, я точно рекомендую зосередитись на практичних роботах і пізніше вивчити теоретичні матеріали.

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

Частина 8: Що я роблю сьогодні

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

Я є членом команди з 12 чоловік, де всі, крім одного дизайнера, є розробниками Rails та JavaScript. Деякі мають 10+ років досвіду, деякі лише кілька років, але лише двоє мають фактичні наукові ступені. Решта ми більш-менш самоучки.

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

У свою чергу, додаток, що стоїть за цим кар’єрним сайтом, має два основні виміри:

  1. Це дозволяє користувачам обробляти бренди роботодавців, призначені для залучення талантів, такими засобами, як публікації про роботу, вміст у соціальних мережах, блог, зображення, відео та GIF-файли.
  2. Він пропонує величезний набір інструментів для обробки трафіку та заявників, таких як відстеження кандидатів, спілкування в чаті, надсилання електронної пошти та надсилання текстових повідомлень, оцінка їх за допомогою тестів, налаштування автоматичних тригерів для виконання певної дії при переміщенні кандидата з однієї стадії на іншу та рекламу вакансій на всіх основних робочих площах, щоб назвати декілька.

Як ми працюємо

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

Звичайно, ми не просто створюємо нові речі. Ми також підтримуємо програму. І в основі цього обслуговування ми маємо, на мою думку, досить незвичну рутину: обов'язок "технічного виклику". Це означає щотижневу поворотну позицію, коли кожен розробник по черзі проводить цілий тиждень, допомагаючи нашим користувачам та допоміжному персоналу в Intercom.

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

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

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

Що я зробив досі

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

Це означало, що від мене очікували розуміння архітектури платформи, набору інструментів розробника, робочого циклу команди, нашого посібника зі стилю, як надати технічну підтримку користувачам та колегам та інших внутрішніх процедур розробки, тестування, налагодження, перегляду та розгортання коду . Іншими словами, БАГАТО нового, для когось, хто щойно вийшов із завантажувального табору.

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

Першим серйозним було оновлення методу, який ми використовували для отримання інформації про користувачів, які зареєструвались у нашому додатку лише електронною поштою. Ми вже інтегрували сторонній API для цього, і ми надсилали запити на отримання таких даних, як повні імена та URL-адреси в профілі соціальних мереж та зображення аватарів.

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

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

Моєю другою власною функцією була розробка того, що ми називаємо "кнопкою заклику до дії", що означає, що ми дозволимо нашим користувачам додавати власні кнопки до своїх кар'єрних сайтів у нашому інструменті редактора.

Наприклад, ми хотіли дозволити їм переспрямовувати на сторінку певної вакансії, певного відділу або якоїсь повністю зовнішньої URL-адреси. Це насправді виявилося набагато простішим, ніж я очікував. Більша частина внутрішньої архітектури вже була на місці, тому все, що мені потрібно було зробити, це створити кілька нових компонентів Ember і додати їх до інших параметрів у редакторі кар’єрного сайту.

Третя особливість, над якою я працював, - це надання нашим користувачам можливості інтегруватися із зовнішніми постачальниками оцінок, тобто вони зможуть направляти кандидатів на тестову платформу, як Hackerrank. Коли вони закінчили тест, результати автоматично надсилатимуться через інтеграцію між нашим API та API провайдера. Це був великий, тому я в основному виступав у ролі помічника старшого розробника (він же гросмейстер нашої команди Ember), відповідального за проект. Тим не менше, це навчило мене безліч методів правильного налаштування інтеграції API та автоматизації робочих процесів за допомогою тригерів.

Мій четвертий проект був найбільшим на сьогоднішній день, і в хорошому і в поганому плані я закінчив робити це більш-менш самостійно. Спочатку весь додаток був побудований у Rails, і більшість подань було переписано за допомогою JavaScript та Ember по одному. Лише в одному з наших основних розділів програми все ще були лише перегляди Rails. Це був так званий розділ «Співробітники», який в основному був основним пунктом призначення для створення, редагування та видалення облікових записів користувачів. Тож було якось важливо, що мій переклад на Ембер був бездоганним.

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

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

Хоча на той час це було відмовно, я тепер усвідомлюю, що його позиція була абсолютно справедливою, і це дало мені важливий урок. У світі розробки програмного забезпечення Agile вовк-одинак ​​не є вибором. Командна робота є основною частиною пошуку продуктивного робочого процесу.

П'ятий проект є останнім на сьогоднішній день, і ми насправді щойно його відправили. Це була наша нова функція для управління новим європейським законодавством про конфіденційність даних (GDPR). Для нас, що перекладено на інструменти побудови, що полегшило кандидатам наших клієнтів видалення їхніх персональних даних з нашої бази даних, а також для наших клієнтів просити кандидатів дозволу зберігати та зберігати свої дані.

Звучить досить прямо, правда? Ну, не було. Зовсім.

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

Вперше з мого початку я був у парі зі старшим розробником та співзасновником, який працював у мене. Тож я відчув, що для мене дійсно важливо показати йому, скільки я навчився з того першого тижня за півроку. Мій випробувальний термін мав закінчитися, і їм незабаром доведеться прийняти рішення, якщо я буду достатньо гарним, щоб утримувати команду. І цим «простим» проектом я вперше додумався, що це буде шматок пирога.

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

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

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

І, до речі, так само подовжили мій 6-місячний трудовий контракт про випробувальний термін, про що мені нещодавно повідомили. Відтепер я штатний штатний працівник, із зарплатою, яку я спочатку просив півроку тому? ?

Частина 9: Чому стати розробником - це найкраще, що я коли-небудь робив

Як ви вже напевно зрозуміли, я закоханий у кодування.

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

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

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

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

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

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

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

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

За кілька тижнів мені виповниться 27 років, і я навіть не уявляю, яке майбутнє за мною. Через три роки, наскільки я знаю, я, можливо, все ще буду в тій же позиції, що і зараз, пишу код для тієї ж компанії. Я можу бути провідним розробником. Я можу бути власником продукту або менеджером. Або я можу бути десь зовсім іншим.

Фріланс віддалено із сонячного раю. Розробка децентралізованих програм на якомусь руйнівному блокчейні. Розробка моделей машинного навчання для боротьби з глобальним потеплінням. Написання алгоритмів космічного корабля для експедицій на Марс. Або побудова власного продукту.

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

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

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

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

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

Вітаємо! Оскільки ви пройшли весь шлях через ДУЖЕ довгу статтю, ви повинні бути такими ж божевільними, як і я. Спочатку я мав два наміри з цим текстом: обробити свої невдачі та успіхи за останні три роки та надихнути інших на шляху, подібні до мого. Я вважаю перший виконаним. Тож якщо у вас є якісь запитання чи відгуки - будь ласка, зв’яжіться! Або в коментарях нижче, або на адресу [email protected]