소프트웨어 엔지니어링 생존 가이드

경력 초기에 도움이되는 자료

Unsplash에서 Fabian Grohs의“노트북 컴퓨터 켜기”

내 경력의 처음 몇 년은 강렬한 학습의 시간이었습니다.

소프트웨어 엔지니어라는 현실에 부딪 쳤고 내가 알지 못하는 많은 기술을 습득해야했습니다. 되돌아 보면, 내가 지금 알고있는 것을 아는 것이 좋을 것입니다.

그래서 저는이 가이드를 처음 몇 년 동안 멘토링 한 개발자의 경험과 저 자신과 동료의 경험을 바탕으로 다른 사람들을 돕기 위해 작성했습니다.

나는 다룰 것이다 :

  • 인터뷰를 최대한 활용하는 방법
  • 소프트웨어 엔지니어로서의 작업에서 생존하고 번성하는 방법,
  • 지속적인 개선을 고려할 때 고려해야 할 리소스

인터뷰

소프트웨어 엔지니어링 분야에서 경력을 쌓기 시작하면 논쟁의 여지가없는 한 가지 사실에 직면해야합니다. 인터뷰는 짜증나.

그들은 관련된 모든 사람들에게 끔찍할 수 있습니다. 면접관이자 면담 관이자 면접은 시간이 많이 걸리고 스트레스가 심하며 미래의 업무 성과에 대한 지표가 심각하다는 것을 증명할 수 있습니다. 그럼에도 불구하고, 그들은 당신과 당신의 이력서를 더 잘 준비하는 데 필요한 악입니다.

전투 준비

소프트웨어 엔지니어링 분야에서 경력을 쌓고 있다면 'FizzBuzz'와 같이 가장 자주 묻는 프로그래밍 인터뷰 질문을 확인하십시오.

“1부터 100까지의 숫자를 인쇄하는 프로그램을 작성하십시오. 그러나 숫자 대신 3 개의 인쇄‘Fizz’와 5 개의 인쇄‘버즈’에 여러 번 인쇄하십시오. ‘FizzBuzz’가 3 ~ 5 번의 배수 인 숫자의 경우”
(코딩 공포)

충분히 간단하게 들립니까?

인터뷰 대상자의 대다수는 복잡한 테스트는 물론이 간단한 테스트에도 실패했습니다.

나는 개인적으로 인터넷에 접속할 수있는 많은 고위직 후보자가이 테스트를 통과하지 못하는 것을 보았다. 따라서 이력서에 프로그래밍 언어가 나열되어 있으면 최소한 FizzBuzz를 수행하는 방법을 알고 있어야합니다. 그렇지 않으면 당신을 포함하여 모든 사람의 시간을 낭비하는 것입니다.

물론 인터뷰에서 살아 남기 위해서는 FizzBuzz 이상을 알아야합니다. 또한 다음 사항을 알고 있어야합니다.

  • 링크 된 목록, 배열, 트리 및 정렬과 같은 기본 데이터 구조 및 알고리즘
  • 문자열을 변경할 수 없는지 여부 및 메모리 관리 방법과 같이 선택한 언어의 일반적인 "gotchas"
  • 클래스 대 객체 및 상속과 같은 객체 지향 프로그래밍 개념.

경력이 시작될 때, 당신이 일에 능숙하다는 것을 입증 할 경험이 없기 때문에 이런 종류의 질문에 빛을 비춰 야합니다. 인터뷰 준비를 할 때 항상 추천하는 두 가지 자료가 있습니다.

  • 많은 코딩 문제와 그 해결 방법, 그리고 해결하기 위해 알아야 할 사항에 대한 요약이 포함 된 환상적인 책인 "코딩 인터뷰 깨기"
  • CodeWars는 다양한 언어를 사용하여 브라우저에서 해결할 수있는 다양한 코딩 문제가있는 웹 사이트입니다. 가장 유용한 부분은 다른 사용자가 어떻게 같은 문제를 해결했는지 확인하는 것입니다. 동일한 문제에 대한 다양한 접근 방식을보고 선택한 언어로 새로운 도구를 배울 수 있습니다.

그 여분의 가장자리를 줘

당신이 할 수있는 몇 가지 일이 있습니다.

먼저, 경험을 전달하는 법을 배우십시오. 이력서를 일관되고 매력적인 내러티브로 요약하는 엘리베이터 피치가 있어야합니다.

또한 자신의 이력서를 아십시오! 어리석게 들리지만 많은 인터뷰 대상자들이 이력서에서 특정 항목을 설명하려고 애쓰는 것을 보았습니다. 이력서에 기재 한 경험에 대한 질문에 답하고 그 직업이 어떻게 더 나은 후보자가되었는지 설명 할 수 있어야합니다.

다음으로 GitHub (또는 다른 공용 저장소)에 표시 할 코드 샘플을 준비하십시오.

보는 것은 믿기 때문에 면접관은 당신의 코드를 볼 수 있다는 것은 놀라운 일입니다. 또한 버전 제어 시스템에 대한 이해를 보여줍니다.

코드 샘플은 너무 복잡 할 필요는 없지만 깨끗하고 코딩 방법이 우수해야합니다. 코딩 인터뷰의 시간 압박없이 코딩하는 방법을 보여줄 수있는 기회입니다.

위의 모든 작업을 완료 한 후에는 오픈 소스 프로젝트에 참여하는 것이 좋습니다. 기존 코드베이스에서 작업하고 다른 프로그래머와 협업 할 수 있음을 보여줍니다.

이것은 실제로 산업 환경에 있지 않고도 산업 환경에서 프로그래밍에 접근 할 수있는 가장 가까운 것입니다. 지금까지 가장 힘들고 시간이 오래 걸리는 항목이므로 위에서 설명한 낮은 교수형 과일을 완성 할 때까지 예약하십시오.

면접관 인터뷰

구직 활동의 서두와 스트레스에서 많은 후보자들은 인터뷰가 양방향 거리라는 사실을 잊어 버립니다. 회사는 귀하가 직무에 적합한 사람인지 파악하려고 노력함에 따라 회사가 귀하에게 적합한 지 알아 내야합니다.

후속 이메일로 발송되는 경우에도 아래 질문 중 일부를 물어보십시오. 회사는 종종 모범적 인 엔지니어링 관행을 따르지 않고 회전하려고 시도 할 수 있으므로 행간을 읽으십시오.

다음은 질문 할 수있는 몇 가지 질문입니다.

"일반적인 근무일은 어떻습니까?"

소프트웨어 엔지니어링 작업은 매우 다양하기 때문에 특정 위치에서 무엇을 기대해야하는지 아는 것이 중요합니다. 예를 들어 서버를 유지하거나 클라이언트와 직접 대화해야 할 수도 있습니다.

적기 :“잘 모르겠습니다.”→ 귀하를 인터뷰하는 사람들이 귀하의 팀에 속하지 않거나 그들이 왜 귀하를 고용하고 있는지 명확하지 않다는 것을 의미합니다.

“소프트웨어는 어떻게 테스트합니까?”

코드의 품질을 확인하기 위해서는 단위 테스트, 수동 테스트 및 자동 테스트의 조합이 이상적입니다.

적기 :“우리는 단지 버그를 쓰지 않습니다.”→ 그 사람들은 정확히 버그를 쓰는 사람들입니다.

“어떤 버전 관리 시스템을 사용하십니까?”

버전 관리 시스템은 공동 작업에 매우 유용하며 전문적인 환경에서 사용하지 않는 이유는 없습니다.

레드 플래그 # 1 :“어, ​​버전 제어 시스템?”→ 멀리, 멀리 뛰십시오.

항상 버전 관리를 사용하십시오.

레드 플래그 # 2 :“<숨겨 지거나 맞춤 VCS 삽입>”→ 시간이 지남에 따라 인프라가 오랫동안 업데이트되지 않았 음을 나타냅니다.

“동료 리뷰를하십니까?”

동료 리뷰 또는 코드 기반으로 들어가기 전에 다른 사람이 내 코드를 보도록하는 것은 바보 같은 실수를 발견하는 환상적인 방법이며 경력을 시작할 때 필수적인 훈련 기회입니다.

적기 :“우리는 서로를 믿습니다!”→ 선임 개발자가 코드를 매우 보호하고 피드백을받지는 않을 것입니다.

"연속 교육을 위해 어떤 프로그램이 있습니까?"

소프트웨어 엔지니어가된다는 것은 기술이 나타나고 성숙하며 어지러운 속도로 구식이됨에 따라 지속적으로 학습하는 것을 의미합니다. 따라서 많은 회사는 대학 및 온라인 강의, 회의 또는 사내 대화 비용을 지불하는 데 사용하는 교육 예산을 가지고 있습니다.

적기 :“자유로운 시간에 온라인으로 물건을 읽는다는 의미입니까?”→ 회사는 현금에 묶여 있거나 개발자가 장기 투자가 아닌 교체 가능한 것으로보고 있습니다.

"사용하는 소프트웨어 개발 프로세스는 무엇입니까?"

프로세스는 실제 세부 사항에 관계없이 소프트웨어 엔지니어링에 필수적입니다. 최적의 프로세스를 구성하는 것의 세부 사항은 격렬한 논쟁의 대상이되지만, 프로젝트에서 작업하는 합의 된 방식의 존재는 혼란을 최소화하고 모두가 같은 페이지에 있도록 보장합니다.

적기 :“우리의 프로세스는 자유형 재즈에서 영감을 얻은 것입니다.”→ 대부분의 부서가 명확한 목표없이 비상에서 비상으로 점프하는 소방 모드에있을 것입니다.

"기술 부채는 어떻게 해결합니까?"

기술 부채는 코드 기반의 오래된 기술과 신속하지만 더티 솔루션의 축적입니다. 이를 다루는 것은 장기적인 건강 상태에 중요하며 지속적으로 이루어져야합니다.

적기 :“우리는 새로운 기능에만 전념하고 있습니다.”→ 코드 기반이 엉망이거나 곧 나올 것입니다.

"회사 문화는 어떻습니까?"

회사 문화는 매우 모호한 개념 일 수 있지만 오픈 오피스 대 큐비클과 같은 작은 것조차도 일상적인 방식으로 동료와의 상호 작용을 변화시킵니다. 일반적인 적혈구는 없지만 그들의 대답이 몇 주 동안 주당 40 시간 이상 살 수있는 것이어야합니다.

소프트웨어 엔지니어로 일하기

이 단계에서 인터뷰에서 성과가 좋았고 인터뷰 담당자가 질문에 어떻게 대답했는지를 좋아한다면 고용 될 것입니다.

축하합니다. 공식적으로 엔지니어입니다.

이제 뭐? 글쎄, 코딩과 작업에 관해 많은 것을 다시 배울 때입니다. 우리는 프로그래머이기 때문에 코드를 논의하면서 시작하겠습니다.

좋은 산업 코드

올바른 산업 코드에는 다음과 같은 속성이 순서대로 있습니다.

  • 코드는 코드보다 더 자주 읽고 유지 관리되므로 읽을 수 있습니다. 코드의 의도는 작성한 후 몇 년 동안 다른 개발자에게 분명해야합니다.
  • 다음은 방어 코딩 모범 사례와 같이 방어 적입니다. 방어 적 코딩은 그 자체로 주제이지만, 그 핵심은 다음과 같습니다. 작성한 클래스와 메소드를 부적절하게 사용한다고해서 코드가 소프트웨어를 충돌시키지 않게해야합니다.
  • 대부분의 경우이 목록에서 마지막으로 최적화되었으므로 걱정할 필요가 없습니다. 그렇다고 선형 솔루션이 존재할 때 O (n³)에서 무언가를하는 나쁜 코드를 작성해야한다는 의미는 아닙니다. 그러나 개발자는 일반적으로 코드의 가독성과 방어력을 훼손 할 때 필요하지 않을 때 과도하게 최적화하려고합니다. 이러한 속성을 희생하는 특정 최적화가 실제로 필요하다는 것을 항상 증명할 수 있어야합니다.

좋은 산업 코드를 작성하는 방법을 알았습니다.

많은 코딩을하지 않을 것입니다

놀랍게도 대부분의 경우 새 코드를 작성하지 않고 대신 다음과 같은 결과를 얻습니다.

  • 디버깅
  • 기존 코드 읽기
  • 회의 또는 이메일 작성
  • 코드를 작성하지 않기 위해 무엇을해야하는지 연구

따라서 코딩 이외의 기술은 경력에있어 매우 중요합니다.

디버깅 및 코드 읽기

  • print 문을 사용하여 디버깅하는 것보다 더 많은 것이 필요합니다. 널리 사용되는 모든 언어 및 기술 스택에는 다양한 강력한 도구가 있습니다. 그들이 디버깅을 산들 바람으로 만들고 수많은 시간을 절약 할 수 있도록 사용하는 방법을 배우십시오.
  • 코드베이스를 이해하십시오. 대부분의 기술 스택에는 코드베이스의 구조를 이해하는 데 도움이되는 일종의 코드 그래프 생성 도구가 있습니다. 엔터프라이즈 IDE에는 일반적으로 해당 기능이 내장되어 있습니다. ReSharper, grep 또는 Sourcegraph와 같은 도구를 사용하여 코드를 탐색 할 수도 있습니다.
  • 제품을 이해하십시오. 얼마나 많은 개발자들이 소프트웨어를“고정”하기 전에 소프트웨어가 어떻게 작동해야하는지 모른다는 것에 놀랄 것입니다. 설명서를 읽으십시오.

생각 정리

의사 소통, 연구 및 멀티 태스킹에 많은 시간을 할애 할 수 있기 때문에 모든 것을 정돈하는 데 도움이되는 도구가 필요합니다.

  • TODO 목록 / 태스킹 : 회사에는 이미 어떤 종류의 태스킹 소프트웨어가 있어야하지만 개인 시스템도 갖추어야합니다. Trello 또는 Todoist와 같은 포스트잇 메모 또는 소프트웨어를 사용하십시오.
  • 메모 : 항상 회의에서 메모하고 기존 문서를 개선하고 개인 기술 자료를 작성하십시오. 예전처럼 Evernote, OneNote 또는 노트북을 사용하십시오. 지나친 것처럼 보일지 모르지만 1 년 후 처음으로 알아내는 데 3 일이 걸리는 모호한 빌드 프로세스를 다시 방문하면 스스로에게 감사하게 될 것입니다. 나는 광범위한 메모를하지 않은 훌륭한 소프트웨어 엔지니어를 만난 적이 없습니다.
  • 차트 / 시각화 : 인간은 시각적 창조물이며 프로세스 및 아키텍처 차트를 작성하면 복잡한 주제를 이해하는 데 도움이됩니다. 다이어그램은 비 기술적 인 동료와 의사 소통 할 때 특히 유용합니다. Lucidchart, Visio 또는 일반 화이트 보드를 사용하십시오.

라이브러리 사용시기를 알아야합니다

짧은 대답 : 거의 항상.

긴 대답 : 99 %의 시간, 휠을 재발 명해서는 안됩니다. 대부분의 소프트웨어 엔지니어링 직책에서 특정 종류의 구현은 완전한 시간 낭비입니다. 그렇다고해서 사용하는 알고리즘과 데이터 구조가 어떻게 작동하는지 알 필요는 없습니다. 사용 방법과시기를 결정하는 데 도움이되기 때문입니다.

효율적인 소프트웨어 엔지니어가 되려면 원하는 라이브러리를 이해해야합니다. 가장 많이 사용되는 언어의 표준 라이브러리는 매우 유용하며 예상보다 더 큽니다. 또한 코드베이스는 추가적인 특수 라이브러리를 활용할 수도 있습니다. 설명서를 읽고 사용시기를 알아야합니다.

또한 시간을 절약 할 수있는 추가 라이브러리를 제안하는 것을 두려워해서는 안됩니다. 그러나 업계에서 사용하기에 적합한 라이브러리를 선택해야합니다. 좋은 도서관은 :

  • 오픈 소스이므로 코드 품질을 직접 확인하고 응용 프로그램에 중요한 버그를 수정할 수 있습니다.
  • MIT 및 BSD와 같은 허가 된 라이센스에 따라 라이센스가 부여되므로 회사에서이를 사용하여 문제가 발생하지 않습니다. 실수로 전체 코드베이스를 공개하지 않도록 GPL에주의하십시오.
  • 성숙합니다. 즉, 얼마 동안 사용되지 않았으며 다양한 기능이 있습니다.
  • 새로운 릴리스가 자주 나오면서 유지 관리됩니다.
  • 다른 회사 나 프로젝트에서 사용하며 승인 스탬프 역할을하며 지속적인 유지 관리를위한 업계 지원을 보장합니다.

지속적인 개선

일상적인 업무에서 더 나은 기술을 배우는 것 외에도 새로운 경력 기회를 창출하기 위해 지속적으로 기술을 향상시키고 새로운 기술을 배워야합니다.

배울 기회는 많으며 많은 것들이 상당히 저렴합니다.

  • 온라인 과정 : 현장에서 최고의 교수로부터 유연한 형식으로 배울 수있는 기회를 놓치지 마십시오. 기존 기술을 보완 할 수있는 코스는 Coursera, Udacity 및 edX (다수)를 확인하십시오.
  • 온라인 석사 학위 : 최근 순위가 높은 대학들 사이에서 온라인 석사 학위는 공식 교육을 계속할 수있는 유연한 방법입니다. 또한 일반적으로 캠퍼스 내 학위에 비해 비용이 적게 들며, 대부분의 프로그램은 전체 학위 비용이 ~ 10,000 달러입니다. Georgia Tech, UT 및 UC San Diego는 이러한 학위를 제공하는 대학 중 일부입니다. 저는 올해 졸업 한 Georgia Tech의 온라인 마스터를 개인적으로 추천합니다.
  • 블로그 : 블로그는 개발자 커뮤니티에서 중요한 부분입니다 (지금 읽고있는 블로그는 놀라지 않습니다). Coding Horror, Joel on Software 또는 Daily WTF와 같은 더 유머러스 한 웹 사이트와 같은 블로그를 통해 소프트웨어 엔지니어로서해야 할 일과하지 말아야 할 일에 대한 좋은 아이디어를 얻을 수 있습니다. 브라우징 미디엄, r / 프로그래밍, HackerNews 또는 기타 피드도 좋은 기사와 블로그로 연결됩니다.
  • 회의 : 마지막으로 회의는 놀라운 학습 기회이므로 회의에 참석하여 회사의 교육 예산을 활용해야합니다. 확인해야 할 훌륭한 회의 목록 (주제와 함께) : GOTO; (일반), 이상한 루프 (일반), PyCon (파이썬), CPPCon (C ++), DEF CON (보안), Fluent (웹 개발). 이 모든 동영상에는 YouTube에서 (대부분의) 대화에 대한 비디오가 있으므로 참석할 수없는 경우에도 배울 수 있습니다!

이 기사가 소프트웨어 엔지니어로 경력을 시작했을 때 무엇을 기대해야하는지에 대한 지식으로 무장하고이 흥미 진진한 여행을 잘 수행 할 수있는 도구를 제공했으면합니다. 읽어 주셔서 감사합니다! 질문이나 제안 사항이 있으면 의견을 남기거나 @AlexievValeri로 트윗하십시오.