Керівництво з виживання програмної інженерії

Ресурси, які допоможуть вам на початку вашої кар’єри

Перші кілька років моєї кар’єри були часом напруженого навчання.

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

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

Я висвітлю:

  • Як зробити найкраще з інтерв’ю,
  • Як вижити (і процвітати) у своїй роботі інженером-програмістом,
  • І на які ресурси слід звертати увагу при постійному вдосконаленні.

Інтерв’ю

Починаючи кар’єру в галузі програмної інженерії, вам доведеться зіткнутися з одним незаперечним фактом. Інтерв’ю відмовні.

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

Підготовка до бою

Якщо ви роздумуєте про кар’єру в галузі програмної інженерії, обов’язково вивчіть деякі найпоширеніші запитання щодо програмування, наприклад, „FizzBuzz“:

«Напишіть програму, яка друкує цифри від 1 до 100. Але для кратних трьом друкується« Fizz »замість числа, а для кратних п'яти друкується« Buzz ». Для чисел, кратних як трьом, так і п'яти, надрукуйте "FizzBuzz". "

Звучить досить просто, так?

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

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

Звичайно, вам потрібно буде знати не лише FizzBuzz, щоб пережити ваші співбесіди. Вам також потрібно переконатися, що ви знаєте:

  • Основні структури даних та алгоритми: такі як зв’язані списки, масиви, дерева та сортування.
  • Поширені “прийоми” у вибраній вами мові, наприклад, чи незмінні рядки, і як управляється пам’яттю.
  • Об'єктно-орієнтоване програмування, такі як клас проти об'єкта та успадкування.

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

  • “Cracking the Coding Interview”, фантастична книга, що включає безліч проблем із кодуванням та їх рішення, а також короткі відомості про те, що потрібно знати для їх вирішення
  • CodeWars, веб-сайт, який має велику колекцію проблем кодування, які ви можете вирішити в браузері, використовуючи широкий вибір мов. Найкорисніше - побачити, як інші користувачі вирішили ту ж проблему. Ви побачите різні підходи до однієї і тієї ж проблеми та вивчите нові інструменти мовою на ваш вибір.

Надайте собі цього додаткового переваги

Є кілька речей, які ви можете зробити, що додасть вам цього зайвого.

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

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

Далі запропонуйте зразки коду для показу на GitHub (або іншому загальнодоступному сховищі).

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

Зразки коду не повинні бути занадто складними, але вони повинні бути чистими та демонструвати належні практики кодування. Це ваш шанс продемонструвати, як ви кодуєте, без часового тиску інтерв’ю з кодування.

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

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

Опитування вашого інтерв’юера

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

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

Ось кілька прикладів запитань, які ви можете задати:

"Як би для мене виглядав типовий робочий день?"

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

Червоний прапор: " Я не впевнений". → Означає, що люди, які беруть інтерв’ю у вас, не будуть у вашій команді, або вони не мають чіткого уявлення, чому наймають вас.

"Як ви тестуєте своє програмне забезпечення?"

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

Червоний прапор: " Ми просто не пишемо помилок, ха-ха". → Саме ці люди пишуть помилки.

"Яку систему контролю версій ви використовуєте?"

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

Червоний прапор №1: "А, система контролю версій?" → Біжи далеко-далеко.

Червоний прапор №2: gt; " → Вказує, що вони, швидше за все, не йдуть в ногу з часом і давно не оновлювали свою інфраструктуру.

"Ви робите рецензії?"

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

Червоний прапор: "Ми просто довіряємо один одному!" → Дуже ймовірно, що старші розробники дуже захищають свій код і не чудово отримують відгуки.

"Які програми у вас є для безперервної освіти?"

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

Червоний прапор: "Ви маєте на увазі читати речі в Інтернеті у вільний час?" → Компанія або прив'язана до грошей, або розглядає розробників як замінних, а не як довгострокові інвестиції.

Original text


"Який процес розробки програмного забезпечення ви використовуєте?"

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

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

"Як ви вирішуєте технічний борг?"

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

Червоний прапор: "Ми зосереджені виключно на нових функціях". → Їхня база кодів безладна, або це скоро буде.

"Яка культура вашої компанії?"

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

Працюючи інженером-програмістом

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

Вітаємо, ви офіційно інженер!

Що тепер? Ну, пора вивчити багато речей щодо кодування та роботи. А оскільки ми програмісти, почнемо з обговорення коду.

Хороший галузевий кодекс

Хороший галузевий код має такі властивості в такому порядку:

  • Читається , оскільки код читається і підтримується частіше, ніж пишеться. Намір коду повинен бути зрозумілим для інших розробників через роки після того, як ви його написали.
  • Захисний, як у наступних найкращих практиках захисного кодування. Захисне кодування - це тема сама по собі, але суть її в тому: Ви повинні переконатися, що неправильне використання класів і методів, які ви написали, не призведе до того, що ваш код виведе з ладу програму.
  • Оптимізований , який є останнім у цьому списку, оскільки здебільшого вам не доведеться турбуватися про це. Це не означає, що ви повинні писати поганий код, який робить щось у O (n³), коли існує лінійне рішення. Але розробники, як правило, прагнуть спробувати оптимізувати, коли в цьому немає потреби, часто на шкоду читабельності та захистності коду. Ви завжди повинні мати можливість довести, що насправді потрібна певна оптимізація, яка жертвує цими властивостями.

Тепер, коли ви знаєте, як написати хороший галузевий код:

Ви не будете робити багато кодування

Це може здивувати, але більшу частину часу ви не будете писати новий код, а натомість ви будете:

  • Налагодження
  • Читання існуючого коду
  • На зустрічах або написанні електронних листів
  • Досліджуючи, що робити, щоб не писати код

Тому навички, крім кодування, будуть не менш важливими для вашої кар’єри.

Код налагодження та зчитування

  • Вам знадобиться набагато більше, ніж налагодження за допомогою операторів друку. Усі широко використовувані мови та технологічні стеки мають безліч потужних інструментів. Навчіться ними користуватися, оскільки вони полегшать налагодження та заощадять вам незліченні години.
  • Зрозумійте основу коду. У більшості технологічних стеків є якісь інструменти генерації графіків коду, які допоможуть вам зрозуміти структуру основи коду. Як правило, в IDE підприємств вбудована така функціональність. Ви також можете дослідити код за допомогою таких інструментів, як ReSharper, grep або Sourcegraph.
  • Зрозумійте продукт. Y ou'll бути здивовані , скільки розробники не знають , як програмне забезпечення повинно працювати , перш ніж вони намагаються «виправити» його. Просто прочитайте документацію.

Організуйте свої думки

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

  • Списки TODO / Завдання: Ваша компанія вже повинна мати якесь програмне забезпечення, але це допомагає також мати персональну систему. Використовуйте нотатки або програмне забезпечення, наприклад Trello або Todoist.
  • Примітки: Завжди робіть нотатки на засіданнях, працюйте над вдосконаленням існуючої документації та створенням особистої бази знань. Використовуйте Evernote, OneNote або блокнот, як за старих часів. Це може здатися надмірним, але ви подякуєте собі через рік, коли переглянете той незрозумілий процес збірки, який зайняв 3 дні, щоб з’ясувати перший раз. Я ніколи не зустрічав хорошого інженера-програміста, який не робив великих нотаток.
  • Діаграми / візуалізації: Люди - це візуальні істоти, і створення діаграм процесів та архітектур допоможе вам та іншим зрозуміти складні теми. Діаграми особливо корисні при спілкуванні з нетехнічними колегами. Використовуйте Lucidchart, Visio або звичайну дошку.

Знати, коли користуватися бібліотеками

Коротка відповідь: Майже весь час.

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

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

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

  • Відкритий код , щоб ви могли самостійно перевірити якість коду та потенційно виправити помилки, які є критичними для вашої програми.
  • Ліцензовано за дозволеною ліцензією, такою як MIT та BSD , тому ваша компанія не стикається з проблемами, використовуючи її. Будьте обережні з GPL, щоб випадково не відкрити всю свою базу коду.
  • Зрілий , тобто він вже деякий час не має і має багатий набір функцій.
  • Зберігається , нові випуски часто виходять.
  • Використовується іншими компаніями або проектами , що виступає печаткою схвалення та забезпечує підтримку галузі для постійного технічного обслуговування.

Постійне покращення

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

Можливостей вчитися багато, і багато з них цілком доступні:

  • Інтернет-курси: Не можна втратити можливість вчитися у кращих професорів у цій галузі у гнучкому форматі. Перегляньте курси Coursera, Udacity та edX (серед багатьох), які можуть доповнити ваші існуючі навички.
  • Інтернет-ступінь магістра: Нещодавня тенденція серед університетів з найвищим рейтингом, Інтернет-ступінь магістра є гнучким способом продовження формальної освіти. Вони, як правило, є менш дорогими в університеті, завдяки більшості програм, які коштують ~ 10000 доларів за весь ступінь. Georgia Tech, UT та UC San Diego - деякі університети, що пропонують такі ступені. Я особисто рекомендую Інтернет-магістратуру Georgia Tech, яку я закінчив цього року.
  • Блоги: щоденники є важливою частиною спільноти розробників (тут немає нічого дивного, оскільки ви зараз її читаєте). Такі блоги, як Coding Horror, Joel on Software або навіть більш жартівливі веб-сайти, такі як The Daily WTF, можуть дати вам гарне уявлення про те, що і як не можна робити як інженер-програміст. Перегляд Medium, r / програмування, HackerNews чи інші канали також приведуть вас до хороших статей та блогів.
  • Конференції: останнє, але не менш важливе, конференції - це дивовижна можливість для навчання, і вам неодмінно слід скористатися перевагами бюджету вашої компанії, відвідуючи їх. Дуже неповний список хороших конференцій для ознайомлення (поряд із їх темою): GOTO; (Загальне), Strange Loop (Загальне), PyCon (Python), CPPCon (C ++), DEF CON (Безпека), Fluent (Web dev). Всі вони також мають відео (більшості) бесід на YouTube, тож ви зможете чогось навчитися, навіть якщо не можете взяти участь!

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