첫 직장에 대한 두려움에서 벗어나세요

영화 '해리포터와 아즈카반의 죄수' 스틸컷

이 세상의 문제는 교육받은 사람은 의심으로 가득 차 있지만, 바보는 자신감으로 가득 차 있다는 것입니다.

찰스 부코스키

나는 최근에 또 다른 일대일 프로그래밍 수업을 가르쳤습니다. 정규수업과 달리 언어구축이나 문제해결을 주제로 하지 않았습니다. 그 학생은 미래의 취업에 대한 고민을 털어놨습니다. 그 학생 자신은 꽤 똑똑했습니다. 강좌에 참석하는 사람 중 한 명은 독창적인 솔루션으로 누구보다 빠르게 전체 프로그램을 완료하지만, 항상 자신을 진심으로 과소평가합니다. 제 생각에는 그러한 의심은 정보 부족으로 인해 발생합니다. 나는 수업 중에 즉석에서 이 공백을 메우려고 노력했습니다.

질문은 다음과 같았습니다.

• 매년 많은 학생들이 대학을 졸업하고 모두 일자리를 찾아 나선다. 그것은 많은 사람들입니다. 그들은 아마도 최고의 인재를 고용할 것이지만 나는 자리를 얻지 못할 것입니다.
• 만약 내가 실수를 해서 바로 해고된다면 어떻게 될까요?
• 일을 하다가 내가 멍청하다는 걸 깨닫고 쫓아내면 어쩌지?

내가 그런 질문에 대답한 사람은 이 학생이 처음이 아니었습니다. 많은 사람들이 그런 증상을 갖고 있으며 대개는 준비 없이 말해야 합니다. 이번에는 나의 독백을 노트에 적어보기로 했다. 한두 문단이면 충분할 줄 알았는데, 결국 전체 기사에 충분했습니다.

이 기사는 내 관점과 내 경험을 바탕으로 관점을 설명합니다. 그러나 우리가 사는 세상은 매우 다양하며 그 안에서 놀라운 일들이 일어납니다. 동의하지 않는 부분이 있거나 경험이 다소 다른 경우 댓글을 작성해 주세요.

이 기사는 개발자를 위해 개발자가 작성했습니다. 그러나 IT 분야에서 테스트, 관리 또는 기타 작업을 수행할 계획이라면 일부 조언도 유용할 것입니다.

그들은 당신을 전혀 고용하지 않을 것입니다

많은 대학이 매년 수백 명의 학생을 졸업한다고 상상하면 불편해집니다. 이렇게 많은 군중과 어떻게 경쟁할 수 있을까요?

불행하게도 모든 졸업생이 충분한 기술 교육을 받은 것은 아닙니다. 당신이 알고 있는 대학생에게 물어보십시오. 그의 그룹에 속한 사람들은 어떻게 "데이터베이스" 또는 "알고리즘 및 프로그래밍의 기초"와 같은 분야의 시험에 합격할 수 있습니까? 30명으로 구성된 그룹에는 실제로 모든 일을 스스로 해낸 "고급" 직원이 3~5명 정도 있을 것입니다. 나머지는 단순히 복사하여 질문에 대한 답변을 입력하고 제출합니다.

제가 혼자 공부할 때도 그랬어요. 그러나 내 경험이 대표적이지 않을 수도 있습니다. 그래서 저는 여러 학생들에게 이런 질문을 했습니다. 대답은 거의 같았습니다. 응답자들은 다양한 대학 출신이었습니다. 이 글의 범위를 벗어나는 이유에 대한 논의는 생략하겠습니다. 본격적인 연구를 할 시간이 부족하므로 이용 가능한 사실을 바탕으로 결론을 도출하겠습니다.

수백 명의 졸업생 중 고용주의 관심을 끄는 사람은 수십 명에 불과합니다.

잘 준비한 유능한 학생에게 진정한 경쟁을 제공할 수 있는 졸업생은 거의 없습니다. 하지만 성실하게 공부했다고 해도 XNUMX차 면접 이후에는 채용되지 않을 가능성이 높습니다. 두 번째 이후에도 마찬가지일 것입니다. 모든 것이 잘 풀릴 수도 있지만 공격이 아니라 포위 공격에 대비하는 것이 좋습니다. 취업에 실패한 시도는 실수를 만회하고 다시 시도해야 하는 이유일 뿐입니다. 면접 준비에 대해서는 이야기하지 않겠습니다. 이 주제에 관해 이미 인터넷에서 많은 글이 작성되었습니다. 인터뷰에는 훈련 프로그램이 설명하는 데 시간이 걸리지 않을 것 같은 뉘앙스가 있다는 점만 말씀드리고 싶습니다. 이 정보를 직접 찾으면 시도 횟수가 줄어들 수 있습니다.

광기는 동일한 행동의 정확한 반복입니다. 몇 번이고 변화를 바라며

알버트 아인슈타인

인터뷰가 광기로 변하는 것을 막으려면 새로운 시도를 할 때마다 개선해야 합니다. 면접 시 받았던 질문을 외우거나 적어보세요. 집에 돌아가면 이 목록을 살펴보고 인터넷을 이용해 자신을 점검해 보세요. 이렇게 하면 귀하와 면접관이 어디에서 실수를 했는지 이해할 수 있습니다. 이런 일도 발생합니다. 성과가 좋지 않은 주제를 검토하거나 연구한 후 다시 시도하세요.

게다가 노동시장의 계절성이 뚜렷하다. 똑똑한 기업은 졸업일을 기준으로 채용을 계획합니다. 봄에는 다른 때보다 신입생을 위한 공석이 더 많습니다. 그러나 현재로서는 경쟁률이 더 높습니다.

바보 - 해고당해

경험이 없는 사람을 채용하면 그 사람에 대한 기대도 있습니다.

직장에 새로 온 사람이 기대하는 바는 다음과 같습니다.

• 일반적인 기술 기반에 대한 지식
• 회사의 주제 영역의 세부 사항을 연구합니다.
• 사용된 도구와 방법을 숙지하세요

일부 조직에서는 신규 이민자에게 사용되는 기술, 도구 및 현지 절차에 대한 교육 과정을 제공합니다. 예를 들어 회사 이메일을 사용할 때의 매너, 위키에서 문서를 변경하는 절차, VCS 작업의 로컬 기능 및 버그 추적기 등이 있습니다.

기술 입문 과정도 있지만 그 유용성은 의심스럽습니다. 고용과 관련하여 고용주는 귀하가 충분한 수준의 지식을 가지고 있다고 확신합니다. 간단한 형식적인 절차처럼 선의로 이러한 과정을 수강하는 것이 가장 좋습니다. 어쩌면 실제로 유용한 것이 있을 수도 있습니다.

작업을 시작할 때 초보자는 긴급하고 복잡하며 동시에 중요한 작업을 해결하는 임무를 맡지 않을 것임을 기억하십시오. 아마도 이러한 속성 중 하나만 있을 것입니다. 또는 간단하지만 긴급합니다. 레이아웃을 수정하고, 다른 사람에게 파일을 보내고, 문제를 재현하세요. 또는 어렵지만 완료할 희망이 없으므로 초보자가 더 많은 갈퀴를 수집합니다. 또는 중요하지만 실험적입니다. 예를 들어, 모두가 오랫동안 원했지만 구현할 시간을 찾을 수 없는 프로젝트입니다.

도구를 익히는 작업은 "어렵고" 인위적입니다. 아마도 이것은 메인 시스템의 단순화된 버전일 것입니다. 이러한 작업은 전체 프로젝트와 동일한 기술 스택과 동일한 도메인 용어를 사용합니다. 이 경우 실행 결과는 최종 사용자에게 제공되지 않습니다. 이는 의욕을 꺾을 수 있지만 이러한 감정에 저항하는 것이 좋습니다. 인위적인 작업은 마치 프로젝트의 운명이 달려 있는 것처럼 성실하게 수행되어야 합니다.

첫 번째 문제 해결의 결과는 면접에 참석하지 않은 동료들 사이에서 당신에 대한 첫인상을 형성할 것입니다.

도구 마스터링 작업의 또 다른 옵션은 "로컬 컴퓨터/테스트 환경에서 프로젝트를 실행"하는 것입니다. 때로는 이 프로세스가 지침에 설명되어 있습니다. 그러나 그들은 일반적으로 오래되었고 어떤 곳에서는 구식입니다. 발생한 문제에 대한 설명과 함께 새로운 지침을 작성하면 프로젝트에 실질적인 이점을 가져올 수 있습니다. 분명히 대학에서는 일부 학문 분야에 대한 보고서를 작성하기 위해 RGR을 작성해야 했습니다. 여기도 거의 똑같습니다. 문서에는 실행을 위해 수행해야 하는 작업이 반영되어야 합니다.

일반적으로 테스트 환경에서 제품을 실행하는 단계는 다음과 같습니다.

• 저장소 복제, 일부 분기 또는 태그로 전환
• 일부 구성 파일을 만듭니다
• 데이터베이스 구조 준비
• 테스트 데이터로 채워라
• 프로젝트를 빌드하거나 컴파일하고,
• 특정 순서로 콘솔 스크립트 세트 실행

시스템을 로컬에서 실행하는 과정에서는 필연적으로 예상치 못한 문제가 발생하게 됩니다.

문제에 대해 발견된 솔루션을 배포 지침에 추가해야 합니다. 그러면 다음에 지침을 따를 때 이러한 문제가 더 이상 발생하지 않습니다. 구성 파일을 작성하고 스크립트를 호출할 때 어떤 값이 어디에 사용되는지, 무엇과 일치해야 하는지 주의해야 합니다. 예를 들어 CI 시스템을 사용하여 프로젝트를 어셈블한 다음 스크립트로 시작하는 경우 브랜치 이름이나 커밋 번호를 어디에 써야 하는지 이해하는 것이 중요합니다. 스크립트에는 데이터베이스의 IP 주소 또는 DNS 이름, 로그인 및 비밀번호 전송이 포함됩니다. 이 경우 테스트 환경에 사용할 주소, 어떤 로그인이 있는지, 어떤 비밀번호를 지정해야 하는지 알아야 합니다.

일부 작업은 숙련된 개발자에게는 간단해 보이지만 인턴에게는 어려울 수 있습니다. 이것은 정상입니다.

개발자는 매일 기술적인 문제를 해결해야 합니다. 숙련된 직원은 이미 많은 문제를 해결한 반면, 신입 직원은 아직 문제에 대처하지 못했습니다. 가장 좋은 방법은 "${작업 이름} 관련 문제 해결" 문서에서 발생한 모든 오류를 기록하는 것입니다. 각 문제마다 원인에 대한 가설을 세우고 인터넷에서 해결책을 찾아 하나씩 시도해 봐야 합니다. 각 시도의 결과도 기록해야 합니다.

문서 형태로 연구를 등록하면 다음이 가능해집니다.

• 머리에서 작은 세부 사항을 제거하십시오. 예를 들어 구성 매개변수, DNS/IP 주소, 콘솔 명령 및 SQL 쿼리가 있습니다.
• 작업이 며칠 동안 지속되면 “어제 무엇을 했는지”를 기억하세요.
• 맴돌지 마세요. 이전에 수행한 작업을 언제든지 읽고 원래 문제로 돌아갔다는 것을 이해할 수 있습니다.
• “오늘 뭐 했어요?”라는 질문에 명확하게 대답하세요. 아직 기성 솔루션이 없더라도 말이죠.

자신의 작업 상태를 동료에게 전달할 수 있어야 합니다.

때때로 동료들은 귀하의 성공에 관심을 갖고 그들의 성공을 공유할 것입니다. 매일 또는 매주 이를 위해 시간을 따로 확보해 두십시오.

직면하고 해결된 문제를 계속 추적하지 않으면 성공을 설명하는 것은 다음과 같습니다. “작업을 수행하려고 했지만 수행할 수 없습니다. 아직도 해결책을 찾고 있어요.” 이 이야기에서는 인턴이 어떤 일을 하고 있었는지 아니면 그냥 앉아서 책을 읽고 있었는지는 확실하지 않습니다. 그에게 도움이 필요한가요? 어제부터 상황이 바뀌었나요?

해결책을 찾기 위해 문서를 보관한다면 “나는 이 일을 하려고 해요. 이런 오류가 있었습니다. 이것이 내가 결정한 방법입니다. 나는 아직 이것을 다루지 않았습니다. 이러한 가설과 해결책이 있습니다. 지금 확인 중이에요."

작업을 어떤 방식으로든 측정할 수 있다면 상태에 숫자가 포함되어야 합니다. 예를 들어, "모듈에 대한 단위 테스트 작성" 작업의 경우 "20개의 테스트를 수행할 계획인데 이제 10개를 작성했습니다."라고 말할 수 있습니다.

자세한 내용을 제공할수록 동료가 귀하가 한 일을 더 잘 이해할 수 있습니다. 이는 동료들 사이에서 당신에 대한 긍정적인 태도를 형성하고 도움이 필요한지 여부를 이해할 수 있게 해줄 것입니다.

부담없이 도움을 요청하세요

위에서 문제가 발생하면 원인과 가능한 해결 방법에 대한 가설을 세워야 한다고 썼습니다. 그러나 가설이 타당하지 않고 문제에 대해 독립적으로 찾은 해결책이 작동하지 않는 경우가 있습니다. 이 경우 도움을 요청하는 것이 좋습니다. 동료의 관심을 남용하지 않으려면 각 문제를 직접 해결해야합니다. 몇 시간 안에 해결책을 찾지 못했다면, 이제 경험이 많은 동료들에게 조언을 구해야 할 때입니다.

시작하기 좋은 곳은 "이전에 이 문제를 겪은 사람이 있나요?"라고 묻는 것입니다. 문제에 대한 간략한 설명과 함께. 오류 메시지나 스크린샷을 첨부하는 것이 좋습니다. 이 메시지를 처음으로 일반 업무 채팅에 보내는 것이 좋습니다. 이렇게 하면 직장에서 정말 바쁜 사람들의 주의를 산만하게 하지 않을 수 있습니다. 무료 동료가 귀하의 메시지를 보고 도움을 줄 수 있습니다.

일반 채팅에서 메시지를 보낸 후 아무도 도움을 주지 않으면 점심 식사, 차/커피 마시기, 테니스 게임 또는 담배 피우기 등 휴식 시간에 숙련된 동료를 만나도록 하십시오. 그래도 안되면 미팅이나 스탠드업에서 애로사항을 보고하세요.

알려진 문제가 해결되면 이 문제가 모두 끝날 수 있습니다. 문제가 새로운 경우 조사가 시작되며 상황에 따라 조치를 취해야 합니다.

최종 사용자에게 필요한 "중요한" 초보자 작업은 지루하고 작을 것입니다. 예를 들어, "보고서에 추가 열 추가", "인쇄된 양식의 오타 수정", "DBMS에서 클라이언트 속성을 로드하기 위한 모델 방법 구현" 등이 있습니다. 이러한 작업의 목적은 초보자가 주제 영역에 익숙해지고 일상 작업에 통합되는 것입니다.

문제를 기술적으로 해결하는 것뿐만 아니라 해당 분야에 대한 지식을 넓히는 것도 중요합니다.

용어는 작업 설명, 채팅 및 대화에 표시됩니다. 익숙한 명사처럼 보일 수도 있습니다. 그러나 정보 시스템의 틀 내에서는 더 특별하고 정확한 의미를 갖습니다. 발견된 용어의 의미는 특수 문서인 용어 사전에 가장 잘 기록되어 있습니다. 사전에 추가할 때는 단어에 대한 이해를 적는 것만으로도 충분하지만, 실제 해독을 위해서는 분석가에게 문의하는 것이 좋습니다. 누락된 경우 프로젝트의 이전 타이머로 이동하세요. 용어 사전을 유지하는 것은 프로젝트의 주제 영역에 익숙해지는 가장 간단한 방법 중 하나입니다.

동료들과 공통 언어를 찾으면 그들은 당신을 새로운 인턴이 아닌 동등한 전문가로 보기 시작할 것입니다.

예를 들어 "모듈에 대한 단위 테스트 작성"과 같은 특별한 작업이 있습니다. 해결책을 찾기 위해 오랫동안 그것에 매달릴 수는 없습니다. 동시에 그것은 매우 진지하며 훈련생 훈련에만 제공되는 것이 아닙니다. 서면 테스트는 애플리케이션의 버그를 줄이고 인적 테스트 시간을 줄여 프로젝트의 안정성을 높입니다. 이상적인 세계에서는 단위 테스트가 개발 중에 즉시 작성되지만 현실은 항상 다릅니다. 모듈 개발자는 모듈을 머리 속에 완전히 보관하고 작성할 필요성을 느끼지 못하는 경우가 있습니다. "모든 것이 분명합니다. 테스트할 것이 무엇입니까?" 때로는 모듈이 러시 모드로 작성되고 단위 테스트를 위한 시간이 남아 있지 않습니다. 따라서 현실 세계에서는 단위 테스트가 없을 수도 있습니다. 따라서 단위 테스트 작성 작업은 초보자에게 할당됩니다. 이렇게 하면 인턴은 프로젝트에 더 빨리 익숙해질 수 있고, 프로젝트를 통해 고임금 전문가의 시간을 절약할 수 있습니다.

인턴과 신입생에게 본격적인 테스터의 역할이 할당되는 경우가 있습니다. 일반적으로 이 작업을 수행하기 전에 제품을 로컬로 배포하고 요구 사항을 읽어야 합니다. 결과적으로 신입 직원은 다음을 기대합니다.

• “이렇게 하면 이렇게 된다. 이는 요구 사항에 없습니다. 그것은해야한다?"
• 버그 추적기의 작업 "요구사항에 이렇게 나와 있지만 실제로는 다르게 작성되었습니다."

이 기사에서는 테스트가 너무 광범위합니다. 비슷한 작업이 주어지면 인터넷에서 작업을 완료하는 가장 좋은 방법을 검색하세요.

말썽 피우면 해고될 거야

정상적인 조직에서 경험이 부족한 직원이 중요한 것에 접근하여 무언가를 망치는 일이 갑자기 발생하면 이를 허용한 사람이 책임을 져야 합니다. 기본적으로 초보자는 중요한 인프라에 접근할 수 없기 때문입니다. 적절한 지도를 통해 그들은 모든 개들이 경험이 없는 훈련생에게 낭비되도록 놔두지 않을 것입니다.

무슨 일이 일어나도 한 가지 사건 때문에 당신을 해고하지 않을 것입니다. 사람들은 실수로부터 배웁니다. 실수를 저지른 인턴은 귀중한 교훈을 얻었고 다른 인턴들과는 매우 다릅니다. 당신이 일을 망친 사람을 해고하면, 다른 사람이 그 자리에 와서 같은 방식으로 일을 망칠 것입니다.

가장 중요한 것은 실수로부터 배우고 다시는 반복하지 않는 것입니다.

사람이 자신의 실수로부터 결론을 내리지 않으면 그 사람에게 작별 인사를 하려고 할 것입니다. 그러나 세상은 다양합니다. 일부 갱스터 조직에서는 첫 번째 실수로 인해 즉시 창 밖으로 던져질 수 있습니다. 하지만 먼저 문의를 하거나 면접을 통해 자세히 알아보는 등 그런 회사는 피하는 것이 좋습니다.

사건을 피하는 것이 좋습니다

비록 당신이 실수로 해고되지 않더라도, 그러한 사건은 당신의 팀과 프로젝트 전체에 원치 않는 문제를 일으킬 것입니다. 따라서 프로젝트 지식베이스의 데이터베이스, 파일, 서비스 인스턴스, 문서의 테이블을 삭제하거나 생성하는 작업에 특히 주의해야 합니다. 새로운 연결 주소를 발견했다면, 그곳에서 무엇을 할 수 있는지 적어도 두 명의 다른 사람들과 확인하십시오. 시행착오가 아닌 적절한 명령을 사용하여 환경에서 귀하의 권리를 확인하십시오. 예를 들어 `ls` 명령을 사용하여 파일을 삭제할 수 있는 권한, `SHOW GRANTS FOR 'user'@'host';` 명령을 사용하여 mysql의 테이블 작업을 수행할 수 있는 권한 등이 있습니다. 거의 모든 도구에서 비슷한 기회를 얻을 수 있습니다.

파일을 편집할 때 만일의 경우를 대비해 원본 사본을 보관해 두세요.

훈련생과 최종 사용자 사이에는 몇 가지 장벽이 구축되어 있습니다.

만약 당신의 제품을 소비자에게 즉시 제공할 수 있다면 당신은 직업을 구하는 것이 아니라 "자유 수영"을 시작할 수 있을 것입니다. 그러나 그러한 기회(동시에 책임)는 없지만 프로젝트에 대한 여러 단계의 제어를 거쳐야 합니다.
첫 번째는 멘토의 검증이다. 그는 기술적인 관점에서 초보자의 결정을 평가합니다. 멘토가 지정되지 않은 경우 멘토를 찾아야 합니다. 이렇게 하려면 프로젝트의 선배 중 한 명을 선택하고 휴식 시간 동안 그에게 해결책을 살펴보도록 요청해야 합니다. 문제가 올바르게 해결되었습니까? 그가 찾고 응답하기 시작하면 멘토를 찾은 것입니다. 그가 그것을 무시한다면 다른 사람에게 물어볼 가치가 있습니다.

다음 단계는 품질 보증입니다. 러시아어 - 테스터. 소련 스타일 - 표준 관리 및 품질 관리 부서. 그들은 훈련생의 성과가 그에게 할당된 업무와 일치하는지 확인해야 합니다. 그들은 코드를 거의 읽지 않을 것입니다. 대부분의 경우 테스터는 개발자가 버전 제어 시스템에 저장하는 빌드된 프로젝트를 확인합니다.

세 번째 단계는 릴리스 관리자입니다. 이 작업을 수행할 별도의 사람이 없을 수도 있지만 여전히 누군가가 역할을 수행합니다. 그는 테스터가 프로젝트가 출시될 수 있음을 확인했는지 확인합니다. 이후 최종 사용자에게 제품을 전달하는 활동을 수행합니다.
소규모 조직에서는 다양한 이유로 이러한 장벽이 존재하지 않을 수 있습니다. 그러나 그들은 초보자에게 중요한 것을 변경하는 작업을 제공하지 않습니다. 누구도 이런 위험을 감수할 필요가 없기 때문입니다.

먼저 전투에 참여해야 합니다. 그러면 살펴보겠습니다.
나폴레옹 보나파르트

이 글이 여러분의 불확실성을 극복하고 첫 이력서를 제출하는 데 도움이 되기를 바랍니다. 물론 먼저 준비를 해야 합니다. 하지만 지나치게 확장할 필요는 없습니다. 당신은 아마도 이미 몇 년 동안 대학이나 전문대학에서 공부했을 것입니다. 다음에는 어디로 갈까요? 결국, 매일 자신에게 "아니오"라고 말하고 전문적인 성장을 멈추는 것보다 전문가로부터 "아니요"라는 말을 한 번 듣고 실수에 대해 노력하는 것이 더 낫습니다.

일단 채용되면 인턴에서 본격적인 팀원으로 성장하는 데 집중해야 합니다. 이러한 유형의 성장은 일반적으로 급여 인상과 함께 제공됩니다.

인내와 인내를 기원합니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

IT 분야의 첫 직장에서 첫 번째 업무는 무엇이었나요?

• 복잡한

• 중대한

• 긴급한

• 위에 해당사항 없음

75명의 사용자가 투표했습니다. 20명의 사용자가 기권했습니다.

첫 직장에서 처음에 무엇을 해야 했나요?

• 로컬로 제품 설치

• 기존 제품 테스트

• 훈련, 가짜 작업 수행

• 고객을 위해 실험적이고 실제적인 프로젝트를 수행하세요.

63명의 사용자가 투표했습니다. 25명의 사용자가 기권했습니다.

귀하의 그룹에서 훈련 중 기술 과목의 과제를 독립적으로 완료할 수 있었던 학생은 몇 명입니까?

• 1의 10

• 1의 5

• 매 초

• 드문 경우를 제외하고 모든 것

70명의 사용자가 투표했습니다. 19명의 사용자가 기권했습니다.

출처 : habr.com