Ръководство за оцеляване на софтуерното инженерство

Ресурси, които ще ви помогнат в началото на кариерата ви

„Включен лаптоп компютър“ от Fabian Grohs в Unsplash

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

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

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

Ще покрия:

  • Как да извлечете най-доброто от интервютата,
  • Как да оцелеят (и да процъфтяват) в работата си като софтуерен инженер,
  • И какви ресурси да обърнете внимание, когато обмисляте непрекъснато подобрение.

Интервюта

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

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

Подготовка за битка

Ако обмисляте кариера в софтуерното инженерство, не забравяйте да научите някои от най-често задаваните въпроси за интервю за програмиране, като „FizzBuzz“:

„Напишете програма, която отпечатва числата от 1 до 100. Но за кратни от три отпечатайте„ Fizz “вместо числото и за кратните на пет отпечатайте„ Buzz “. За числа, кратни на три и пет, отпечатайте „FizzBuzz“. “
(Кодиране на ужасите)

Звучи достатъчно просто, нали?

Е, по-голямата част от анкетираните не успяват този прост тест, камо ли по-сложните му варианти.

Лично съм виждал много кандидати за ръководни длъжности да провалят този тест, докато имат пълен достъп до интернет. Затова се уверете, че ако на вашето резюме е посочен език за програмиране, знаете как да направите поне FizzBuzz в него. В противен случай просто губите времето на всички, включително и вашето.

Разбира се, ще трябва да знаете повече от FizzBuzz, за да оцелеете в интервютата си. Трябва също така да се уверите, че знаете:

  • Основни структури и алгоритми на данни: като свързани списъци, масиви, дървета и видове.
  • Често срещани “gotchas” в избрания от вас език, например дали низовете са неизменни и как се управлява паметта.
  • Обектно ориентирани програмиране понятия като клас срещу обект и наследяване.

В началото на кариерата ви ще трябва да блестите върху подобни въпроси, тъй като нямате опит, за да докажете, че ще бъдете добри в работата си. Има два ресурса, които винаги препоръчвам, когато се подготвям за интервюта:

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

Подарете си това допълнително предимство

Има няколко неща, които можете да направите, които ще ви дадат това малко нещо допълнително.

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

Освен това, познайте собственото си резюме! Звучи глупаво, но видях много интервюирани да се борят да обяснят конкретен елемент от резюмето си. Би трябвало да можете да отговорите на въпроси за всяко преживяване, което изброявате в резюмето си, и да обясните как това ви е направило по-добър кандидат за работата.

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

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

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

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

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

Интервю на вашия интервюиращ

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

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

Ето някои примерни въпроси, които бихте могли да зададете:

"Как би изглеждал типичен работен ден за мен?"

Важно е да знаете какво да очаквате от конкретна позиция, тъй като работните места в Software Engineering се различават доста. Може да се очаква да поддържате сървъри или да разговаряте директно с клиенти, например.

Червено знаме: „Не съм сигурен.“ → Означава, че хората, които интервюират с вас, няма да са във вашия екип или нямат ясна представа защо ви наемат.

„Как тествате софтуера си?“

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

Червено знаме: „Ние просто не пишем бъгове, хаха.“ → Тези хора са точно тези, които пишат бъгове.

„Каква система за контрол на версиите използвате?“

Системите за контрол на версиите са изключително полезни за сътрудничество и има нулеви причини да не се използва такава в професионална среда.

Червен флаг №1: „Ъ-ъ, система за контрол на версиите?“ → Бягайте далеч, далеч.

Винаги използвайте контрол на версиите.

Червен флаг №2: „<поставете неясен или персонализиран VCS>» → Указва, че най-вероятно не са в крак с времето и не са обновявали инфраструктурата си от дълго време.

„Правите ли партньорски проверки?“

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

Червено знаме: „Ние просто се доверяваме един на друг!“ → Много вероятно е, че по-старите разработчици са много защитни от своя код и не са много добри в получаването на обратна връзка.

„Какви програми имате за непрекъснато образование?“

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

Червен флаг: „Имате предвид да четете неща онлайн в свободното си време?“ → Компанията е или привързана за пари или вижда разработчиците като заменяеми, а не като дългосрочни инвестиции.

„Какъв е процесът на разработка на софтуер, който използвате?“

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

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

„Как се справяте с техническия дълг?“

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

Червен флаг: „Ние сме изключително фокусирани върху новите функции.“ → Кодовата им база е бъркотия или ще бъде скоро.

„Каква е културата на вашата компания?“

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

Работа като софтуерен инженер

На този етап, ако сте се представили добре в интервютата си и сте харесали как интервюиращите отговарят на вашите въпроси, вероятно ще бъдете наети.

Поздравления, Вие официално сте инженер!

Сега какво? Е, време е да научите много неща за кодирането и работата. И тъй като ние сме програмисти, нека започнем с обсъждане на код.

Добър индустриален код

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

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

Сега, когато знаете как да напишете добър индустриален код:

Няма да правите много кодиране

Може да дойде като изненада, но през повечето време няма да пишете нов код, а вместо това ще бъдете:

  • Отстраняване на грешки
  • Четене на съществуващ код
  • При срещи или писане на имейли
  • Проучете какво да направите, за да не пишете код

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

Код за отстраняване на грешки и четене

  • Ще ви е нужно много повече от отстраняване на грешки с помощта на отчети за печат. Всички широко използвани езици и технологични стекове имат разнообразни мощни инструменти. Научете се да ги използвате, тъй като те ще направят отстраняване на грешки и ще ви спестят безброй часове.
  • Разберете кодовата база. Повечето технологични стекове имат някакви инструменти за генериране на кодови графики, които ще ви помогнат да разберете структурата на кодовата база. Като цяло Enterprise IDE имат вградената функционалност. Можете също да проучите кода, като използвате инструменти като ReSharper, grep или Sourcegraph.
  • Разберете продукта. Ще се изненадате колко разработчици не знаят как софтуерът трябва да работи, преди да се опитат да го „поправят“. Просто прочетете документацията.

Организирайте мислите си

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

  • TODO списъци / Задачи: Вашата компания вече трябва да има софтуер за задачи от някакъв вид, но това помага и да има лична система. Използвайте бележки или софтуер като Trello или Todoist.
  • Забележки: Винаги си водете бележки на срещи, работете за подобряване на съществуващата документация и създаване на лична база от знания. Използвайте Evernote, OneNote или тефтер, както в стари времена. Може да изглежда като излишно, но ще се благодарите година по-късно, когато преразглеждате този неясен процес на изграждане, който ви отне 3 дни, за да разберете за първи път. Никога не съм срещал добър софтуерен инженер, който не правеше обширни бележки.
  • Диаграми / визуализации: Хората са визуални създания и създаването на диаграми на процеси и архитектури ще ви помогне и на другите да разберете сложни теми. Диаграмите са особено полезни при комуникация с нетехнически колеги. Използвайте Lucidchart, Visio или обикновена бяла дъска.

Знайте кога да използвате библиотеки

Кратък отговор: Почти през цялото време.

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

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

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

  • С отворен код, така че можете сами да проверите качеството на кода и потенциално да поправите грешки, които са критични за вашето приложение.
  • Лицензиран под разрешителен лиценз като MIT и BSD, така че вашата компания не се сблъсква с никакви проблеми, като я използва. Внимавайте с GPL, за да не случайно да отворите цялата си кодова база.
  • Зрял, т.е. той е излязъл от известно време и има богат набор от функции.
  • Поддържа се, като новите издания излизат често.
  • Използва се от други компании или проекти, което действа като печат на одобрение и гарантира, че има промишлена поддръжка за продължителна поддръжка.

Непрекъснато усъвършенстване

Освен да научите уменията, които ще ви направят по-добри в ежедневната работа, ще трябва непрекъснато да подобрявате уменията си и да научавате нови, за да създадете нови възможности за кариера за себе си.

Възможностите за учене са много и много от тях са доста достъпни:

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

Да се ​​надяваме, че тази статия ви въоръжи със знанията какво да очаквате от началото на кариерата ви като софтуерен инженер и ви даде инструментите да се представите добре на това вълнуващо пътешествие! Благодаря за четенето! Ако имате въпроси или предложения, моля, оставете коментар или туитър @AlexievValeri.