무엇을 준비해야하지?
스타트업에 프론트 개발자로서 취업하기 위해 무엇을 준비해야 하는지 찾아보았다.
우선 남들 다 하듯이 포트폴리오를 만들어야 할 것 같아서, 1주일동안 이것저것 참고하면서 웹페이지 하나를 만들어 github page로 올려두었다. 포트폴리오도 딱히 참고 삼을만 할 것이 없어서 어렵게 어렵게 만들었는데, 아무리 자유양식이라지만 뚝딱하고 만들어보려고하니 막막한점이 없잖아 있었다.
허접한 실력이지만 누군가에게 영감을 줄 수 있을 것이라 생각해서 올려봐야겠다.
그러나 포트폴리오는 어디까지나 포트폴리오.
내가 인사팀의 실무자 혹은 회사의 창업자라 생각해보고 곰곰히 생각해보았다.
나는 누구를 뽑을 것인가? 어떤 사람을 뽑을 것인가?
1. 상대방의 입장에서 생각해보기
첫번째로 능력이다.
회사는 이윤을 내기 위한 곳이다. 거대 대기업이야 사람을 뽑아놔서 교육도 시켜주고 키울 수 있을 것이다. 하지만 스타트업이라면 어떨까. 사람 하나하나가 지대한 영향을 끼치는 곳이다. 워낙 바쁜 곳이라서 사람 키워줄 만큼 시간도 넉넉하지 않을 것이다. 그렇다면 그만한 역량을 보여줄 수 있는 사람을 원할 것이다. 그럼 그 사람의 역량을 판단할 수 있는 기준은 어디서 나오는가?
보통은 널리 알려진 표본을 기준으로 삼을 것이다. 거기에서 조금 자신만의 스타일로 커스터마이징된 변형이 나올 수 있지만 , 기본은 항상 같다. 기본이 안되어 있다면 어떤 스킬을 쌓아도 사상누각이기 마련이다. 쟁쟁한 현업에서 열심히 일하고 계시는 분들이 이것을 모를리 없다.
나는 기본이 잘 안잡혀 있다. 차라리 잘 되었다. 어렴풋이 알고 있던 개념을 확실히 잡고 넘어가자!
두번째로 인성이다.
여기서의 인성은 나랑 참 잘 맞겠다. 어우 저사람이랑은 일하기 싫다. 같은 지극히 주관적인 가치판단적인 성질이다. 즉, 그 분이 보시기에 좋으셨다더라 하는 것이다.
어차피 그 회사에서 기술적인 면이 아닌 인성적으로 나를 안좋게 보았다면 내게도 이로울리 없다. 구인구직활동은 자신의 노동력을 팔기 위한 사람들이 모인 일종의 시장같은 것이라는 글을 보았다. 일단 서로가 거래를 하기 시작했다면 그 때는 거래를 넘어서 보다 깊은 관계로 발전 할수 있어야 한다. 매일 부대끼고 사는 곳에서 자신과 맞지않는 사람들과 하루의 3분의 1을 보낸다면 스트레스로 눈이 돌아가버릴 것이다 . 군대에서 이미 겪어보았는데 또다시 그러고 싶지는 않다.
('17.4.1 추가) -페이팔 마피아중 한명인 피터틸의 Zero to One 이라는 책에서도 설명한다.
...우리는 이력서를 꼼꼼히 검토하거나 단순히 가장 재능있는 사람들을 고용해 마피아를 만든 것이 아니다...(중략)...한 사람씩 따지면 매우 인상적인 사람들이었지만 이상하게도 그 안에서 서로의 관계는 튼튼하지 못했다. 하루종일 함께 시간을 보냈지만 사무실 밖에서는 서로 할 얘기가 별로 없는 사람들이 대부분인 것 같았다. 서로 좋아하지 않는 사람들과 왜 함께 일하는 걸까? 많은 사람들이 돈을 벌려면 이런 일은 어쩔 수 없는 희생이라고 여기는 것 같다. 하지만 사무실을 그저 직업적 관점으로만 보고, 거래를 하기위해 프리랜서들이 들락거리는 곳이라고 여긴다면, 서로를 차갑게 대하는 것보다도 오히려 못한 것이다... (중략)...재능도 있어야 하지만, 특히 우리라는 사람들과 함께 일하는 것을 신나게 생각해야 했다. '페이팔 마피아'는 그렇게 시작되었다.
('18.5.12 추가)
참 신기하다. 내가 작년에 썼던 글을 읽고 있노라니 구구절절 옳은 말만 써두었다.
자신과 맞지 않는 사람들과는 어떻게 지내야할까? 나는 이미 겪어본 바 사람이 싫어지면 그 사람이 뭘 하든 간에 모든 것이 미워보이는 것을 알고 있다. 사실 으르렁 거리며 싸우는 것이 차라리 낫다고 생각한다. 가장 힘든 것은 저 사람의 목소리와 형태를 보는 것만으로도 힘든데 그 내색을 하지 못할 때이다.
나와 맞지 않는 사람과 이야기를 하는 것은 생각보다 에너지가 빨리 소모된다.
어떻게 대처해야 할지 아직도 어렵다. 그 사람에 대한 나의 불편한 점을 이야기 했음에도 불구하고 전혀 고쳐지지 않는다면 나는 어떻게 해야 할까. 내가 털어놓은 속내를 다른 사람이 똑같이 알고 있다면 나는 그저 그 이야기를 듣고 가만히 있어야 하는 것일까.
사실 내가 작년에 이런 글을 써놓고도 정작 내가 행하지 못함에 대해서 굉장한 모순을 느끼는 바이다.
몰랐다. 그 회사의 구성원 한 명 한 명이 모두 영향을 끼칠 수 있음을. 단순히 대표가 모든 것을 좌지 우지 하지 않는다는 것을 말이다.
물론 회사는 그 회사의 대표를 따라가고 닮아가는 경향이 무척이나 세다고 한다. 하지만 그 와중에서도 구성원들 역시 그 문화를 만들어가는 일원들이니까..
--
인성에 대한 부분이라면 따로 준비할 필요가없다. 내가 그 회사에 맞출 필요도 없을 뿐더러, 회사도 그런 것을 바라지 않을 것이다. 내가 창업자라면 그렇게 자신을 회사에 맞추는 사람들을 더 경계할 것이다. 본인 스스로도 스트레스일뿐만 아니라 내 조직전체에도 악영향을 미칠 것은 뻔하다.
그저 있는 그대로를 보여주는 것이다. 거짓없이 대한다.
나는 믿는다. 회사의 인사업무에서 이러한 것들을 걸러내지 못한다면 그 조직은 이미 가망이 없는 곳이다. 그런 곳에서 나의 역량을 키우지 못할 것이라고 확신한다. 회사의 업무는 곧 조직원인 사람에게서 나오고, 그 사람을 뽑는 인사업무가 허술하다면 그 회사의 미래는 없는 것이다.
2. 개발자 면접 예상 질문 준비
이렇게 정리하고나니, 기술적인 부분에서의 기초부분을 다지는데 당분간 힘을 좀 써야겠다.
이미 취업에 성공한 형에게 어떤식으로 준비해야 하는지 키워드를 알려달라고 했다.
그 키워드를 치니까 바로 저 글이 검색되었다. 전 세계적인 개발자가 참여하고 있다고 하니
그 표준성은 입증되었을 것이라 생각한다.
하나하나 준비를 해본다.
이번 포스트에서는 먼저 일반 질문들에 대하여 알아본다.
General Questions:
- What did you learn yesterday/this week?
이 질문의 요지는 최근 무엇에 관심이 있는지, 어떤 것을 느끼고 배우고 있는지를 알아보는 근황같은 질문이다. 면접당시에 준비해도 늦지 않을 것 같다. 게으름만 피우지 않는다면 답변 못할 이유는 없을 것이다.
- What excites or interests you about coding?
조금은 난해한 질문이다. 코딩의 기술적인 부분이 좋다는 것인지, 코딩이라는 행위 자체에서 어떤 점을 느낄 수 있는지 물어보는지 모르겠다. 그러면 2가지 전부 생각해보면 된다.
먼저 코딩이라는 행위자체가 어떤 점이 좋았는지 이야기 해본다.
내게 코딩이라는 행위는 놀이 그자체와도 같다. 조각조각을 맞춰서 하나의 결과물을 만들어 내는 것에 흥미가 많은 편이기때문이다. 이와 관련해서 짤막하게 어린 시절 이야기를 해보겠다.
어릴 적부터 레고를 가지고 놀기를 좋아했다. 집이 잘사는 편이 아니어서 나에게 장난감이라고는 레고 한 세트 뿐이었다. 레고라는 것이 일정 테마를 가지고 있기 마련인데, 한 두번 만들고나면 질리기 마련이었다. 다른 장난감이 없던 나에게 선택지는 그 레고를 나만의 방식으로 재 창조를 하는 방법밖엔 없었다. 원래 모양과는 상관없이 나는 레고를 통해 로보트를 만들고, 사람들을 만들고, 총을 만들어서 나만의 이야기 속에 푹 빠지곤 했다. 그렇게 초등학교 내내, 중학교 1학년까지도 레고를 가지고 놀았던 기억이 떠오른다.
처음 코딩을 하게 되었을때가 딱 그랬다. 몇 가지 글자를 적은뒤 엔터를 눌렀을때, 내가 원하는 문자열이 모니터화면에 찍히는 것은 어린시절 나만의 레고이야기에 입성하는 듯한 착각을 들게 만들었다. 손끝에서부터 전해져 오는 짜릿한 전율을 잊을 수가 없다. 재미있었다. 조그마한 성공의 경험은 그렇게 커져가기 시작했다. 나는 코딩의 레고같은 점이 너무 좋다. 준비물이 있고, 내 손으로 뚝딱뚝딱해서 나만의 이야기를 만들 수 있는 것이 어린시절의 김영태로 다시 돌아가게 해주기 때문이다. 아마 죽을때까지 하나의 놀이로써 즐길 것 같다.
코딩의 기술적인 부분에서 어떤점이 흥미로운가에 대해 생각해본다.
기술적인 부분인지는 모르겠으나, 그 다양성과 창의성이 너무 좋다고 생각한다. 코딩은 수많은 언어로 이루어진다. 흥미로운 점은 같은 언어, 같은 목적으로 만들어도 그 목적에 달할 수 있는 길이 수백가지는 생겨날 수가 있다. 그러면서도 디자인패턴같은 것들이 있어, 지루하고 재미없는 부분들은 후딱 해결해나가는 간편함에 대한 열망도 엿보인다. 큰 맥락을 보고있자면 분열했다가, 통합했다가를 반복해가면서 부분부분 진화해 나간다는 것이다. 마치 하나의 생명체가 환경을 견뎌가면서 점차 적응해나가는것 처럼 느껴지기도 한다.
- What is a recent technical challenge you experienced and how did you solve it?
가장 최근에 경험했던 기술적 과제가 무엇이고, 어떻게 해결했냐는 질문.
바로 떠오르는 것이 있다.
이미 블로그로 정리한 것이 있어 이것으로 대체한다.
- What does CORS stand for and what issue does it address?
위 블로그에 마침 잘 정리되어있어서 생략!
- What UI, Security, Performance, SEO, Maintainability or Technology considerations do you make while building a web application or site?
웹사이트를 구축하는 동안 UI,보안, 성능, SEO(검색엔진 최적화), 유지보수, 기술에 관하여 당신이 고려해야할 사항은 뭐냐고 묻는다.
먼저 유지보수에 대해 알아보았다.
kocw라고 한국형 ocw 사이트이다. 여기서 대구카대 김행곤 교수님의 자료를 공부하였다.
으아. 학문적으로는 겁나 딱딱하구나. 내 생각대로 필기해야지.
유지보수란 간단히 말하면 내가 아닌 다른 누군가가 코드를 봤을 때, 빨리 이해하고 쉽게 코드를 고칠 수 있는가이다. 물론 미래의 나도 내가 아닌 다른 누군가이다. (한 3개월만 지나도...)
웹사이트를 구축하는 동안 내가 유지보수에 대해 고려해야할 사항은 무엇일까?
자료를 보니 어려운 말로 4가지가 있다. 프론트 개발자에게 중요한 것은 그 중에서도 완전화유지보수 Perfective maintenance 라고 생각한다. 주로 새로운 혹은 변경된 사용자의 요구, 사용자 인터페이스에 대한 부분에 대한 유지보수라고 하는데, 프론트 개발자가 맡고 있는 부분이 바로 이점이기 때문이다. 나머지 수리유지보수, 예방유지보수, 적응유지보수 모두 중요한 개념이다.
기능별로 코드를 잘 나누고, 주석을 잘 달아놓는 것은 필요하다. 하지만 더 근본적인 문제는 그러한 코드와 주석들이 쓸모있게 만드는 것인데, 사용자가 필요로 하지 않는 기능을 열심히 만들면 그만한 비용낭비가 없을 것이다. 실제로 나는 최근 프로젝트를 하면서 그것을 많이 느낀다. 정말 핵심 기능을 하는데 시간을 쏟지 않고, 자잘자잘한 기능을 구현하는데 더 열중했다. 물론 만들때는 성취감도 들고 좋았다. 하지만 그것은 분명 비용낭비였다. 오히려 아는 형님께 무슨기능인지 몰라 더 헷갈렸다는 피드백을 받을 뿐이었다. 정의를 다시 한번 돌이켜본다. 유지보수는 소프트웨어의 생명주기동안 오류와 새로운 기능을 추가하기위해 변경하는 과정이다. 아아 쓸모없는 기능을 만드는 것만큼 에너지 낭비는 없다. 그런 것을 미연에 방지하기 위해서는 사용자의 세부조정 요구와 강도높은 참여가 절실히 필요하다고 생각한다. 최종 사용자의 요구에 맞게 설계를 하고 개발을 하고 개발을 하면서 형상관리를 잘해놓는것이 최선이지 않을까? 궁금하다. 실무를 겪어보면 다른 생각을 하게 될까?
UI 도 유지보수와 비슷한 답이 나올 것 같다. 말그대로 User Interface니까. 사용자의 경험에서 고려할 것은 사용자가 간편하고 보기 쉽게 만드는 것이 답이 아니다. 그것은 부가적인 것이다.
드릴을 사려고 하는 사람은 드릴을 사는게 아니라 구멍을 뚫고 싶은 것이다. 항상 그 본질을 고려해가면서 인터페이스를 만들어야 할것이다.
보안은 항상 중요하다. 최근 여기어때라는 숙박어플리케이션이 SQL 인젝션을 통해 개인정보가 털렸다는 소식을 들었다. 회사의 피해도 피해지만, 개인정보가 노출되었다는 사실에 얼마나 많은 사람들이 마음 상했을까. 한국에서는 우스갯소리로 '나의 개인정보는 공공재이다' 라는 말이 있다.
웹사이트를 만들때 개인정보의 책임은 개인보다는 그 서비스를 하는 제공하는 쪽에 있다고 생각한다. 개인에게 전부 돌리는 것은 서비스 제공자로서 의무를 다하지 않는 것이다. 힘겹고, 어려운 작업일 것이다. 그러나 그것을 극복하게 되었을때, 다른 제품보다 우위에 설 메리트가 될 것은 자명하다.
SEO에 대한 것은 어떻게 생각해야 할까. 마케팅의 파워는 블로그를 운영하면서 절실히 느끼고 있다. 검색엔진최적화 역시 마케팅의 일환이라고 본다. 결국 그 대상과 대상이 존재하는 환경에 맞추는 것을 고려해보는 것이 최선일 것이다. 나는 구글블로그를 선택한 이유가 대다수 개발자들이 네이버보다는 구글링을 한다는 사실을 알고 있었기 때문이다. 실제로 네이버에 블로그를 했다면 지금같은 조회수(하루에 100명도 채 안되지만 꾸준히 증가하고 있다!) 는 기대하기 어려웠을 것이다.
- Talk about your preferred development environment.
빠르고 간편한 개발환경이 제일 최적 아닐까. 반복되고 귀찮은 것들은 단축키 하나로 해결 할 수 있는 환경이 가장 좋을 것이다. 개인화를 할 수 있는 환경이 가장 좋은 개발환경이라고 생각한다.
- Which version control systems are you familiar with?
git. 아무래도 제일 대중적이고, 그렇기에 배울 수 있는 자료도 많이 존재해서.
- Can you describe your workflow when you create a web page?
아직까지는 개인, 소규모 프로젝트만 했기때문에 workflow라고 해봤자, 만들고 보고, 만들고 보고 하는 정도밖엔 안해보았다... 페이지의 구성요소 혹은 페이지 전체를 만드는 워크플로우라면
먼저 HTML 태그로 뼈대를 만든다. 건축물로 치면 비계를 만드는 느낌?
그다음에 CSS로 이미지를 붙이고 마지막에 JS로 움직임을 준다. 하지만 이대로 지켜본적은 없고 당장 어떻게 움직이는지 궁금해서 2번째와 3번째를 동시에 하는 편이긴 하다.
- If you have 5 different stylesheets, how would you best integrate them into the site?
css 부분은 심도 있게 공부한적이 없어서 찾아서 공부를 해야할 것으로 보인다.
일단 지금 생각은 비슷한 레이어, 혹은 기능하는 것들끼리 잘 묶는 방법밖엔 안보이는데...
--
만약에 디자인을 표현하기 위해 8개의 다른 Stylesheet를 가지고 있다면, 사이트에서는 어떻게 통합하실 건가요?
- 파일의 연결법을 찾아내세요.
- Build system을 이용한 결합없이,
@import를 사용하면 점수를 깎으세요.
--
비슷한 질문에 대한 모범답안인데 연구해봐야겠다. 특히 빌드시스템같은 경우는 더더욱 공부해볼 필요가 있어 보인다.
- Can you describe the difference between progressive enhancement and graceful degradation?
이 블로그에 잘 설명이 되어있다.
잘보니 순서의 문제인듯 하다. HTML CSS JS 순을 진보의 방향으로 바라보자.
우아한 낮춤, 적절한 퇴보라고 번역이 되는 graceful degradation은 결국 자바스크립트에 의존한 웹이라는 이야기다. 요즘이야 대부분의 브라우저에서 자바스크립트를 잘 지원하지만 만약 자바스크립트가 지원되지 않는다면? 그때는 CSS 단계에서 대안책을 만들어 놓는 것이다 .
다시말하면 최신의 기술로 먼저 만들어놓고, 만약 지원되지 않는 기기가 있다면 사용자경험을 포기해서라도 우아하게 만든다는 의미라고 볼 수 있겠다.
점진적 향상이라고 불리우는 progressive enhancement의 개념은 정확히 그 반대이다.
HTML CSS JS 순으로 견고하게 살을 붙여나가는 방식이다.
HTML로 먼저 컨텐츠와 기본뼈대를 만들면 CSS로 시각적으로 이쁘게 만들어놓는다. 그 후에 JS로 사용자 경험을 추가 시키는 것이다. 원래 표현하고자 했던 기본적 컨텐츠가 단단하게 짜여져 있기때문에 설사 JS가 지원이 잘안되더라도 본래의 기능을 쉬이 손실하지 않는다는 것.
잊지말아야 할 원칙 하나는 “Web for All”. 팀 버너스 리의
웹의 힘은 그것의 보편성에 있다. 장애에 구애없이 모든 사람이 접근할 수 있는 것이 필수적인 요소이다.
(The power of the Web is in its universality, Access by everyone regardless of disability is an essential aspect.)
라는 것이겠지요.
출처: http://webprogrammer.tistory.com/1964 [개발자(開發者) a developer]
위 블로그 마지막 말에 백퍼 공감한다면 Progressive enhancement가 좀더 웹에 가까운 방법론이 아닐지
- How would you optimize a website's assets/resources?
엄청난 글의 장문글이 들어있다 약 30가지 방법을 제시해주는 데 깊게 읽어볼 만한가치가 있어 일단은 주소만 가져다 놓았다.
요지는 이런 것 같다.
HTTP 요청을 줄인다(합칠수 있는 것은 왠만하면 합치라는 것). 무엇이라도 하나 빨리 띄워라. 크기가 크다면 분산시스템을 사용해라(CDN적극 사용), 쿠키는 최대한 가볍게!(쿠키는 요청에 묻어서 가기때문에 요청자체가 느려지는 주범이 될 수 있음)
- How many resources will a browser download from a given domain at a time?
8인 IE를 제외하고는 6이라고 한다. 이에 대한 이유는 책에서 본적이 있는 것 같은데...
- Name 3 ways to decrease page load (perceived or actual load time).
사실상 최적화 문제와 같아보인다.
- Describe how you would create a simple slideshow page.
2가지 방법이 있다. 자바스크립트를 사용하는 것과 사용하지 않는 것.
슬라이드 한장한장을 div 태그로 감싸놓고 하나하나의 DOM 객체로 만들어놨다고 가정한다.
자바스크립트로 만드는 것은 배열을 이용하는 것이다. 그리고 next나 previous 요청이 들어오면 그것에 맞게 배열값들이 수행할 수 있도록 만들어놓는다. 하지만 이것은 굉장히 느리다. 만약 100장이 넘은 슬라이드쇼가 생길 경우 배열에 담는 시간을 고려해야 할 것이다.
순차적으로 로딩된다고 했을때, 첫번째 화면은 바로 보여주고 나머지 부분은 보이지 않고있다가 앵커태그에 #을 이용해 이동해보는 것을 어떨까?
말그대로 simple slideshow라면 아래방법이 더 어울릴 것 같다
- If you could master one technology this year, what would it be?
MEAN 스택이다. 풀스택으로 활동해보고 싶기 때문! 전체적인 맥락을 그려보고 싶다.
- Explain the importance of standards and standards bodies.
기준 혹은 표준의 중요성을 설명해달라고한다.
이런 비유를 떠올려보았다. 태초에 한 쌍의 새가 있다고 치자. 이 한쌍의 새 이름이 바로 표준(standards)이다. 이 새들은 기본적인 생존전략으로 초식을 하고, 나무위에서 둥지를 짓고 살아간다. 이 새의 자손들은 주위환경에 따라 진화를 한다. 이 새들은 환경에 적응하면서 점차 자신들만의 구색을 갖추어 나간다. 어떤 인간이 이 새를 연구하고 관찰한다고 해보자. 이 관찰자의 이름은 유지보수이다. 유지보수는 표준이라는 새들을 관찰하며 그들의 습성을 익혀놓았다. 후에 새들이 각기 다른방식으로 진화를 해나갔다. 어떤 녀석들은 초식을 하되 열매를 먹고, 어떤 녀석들은 풀을 뜯어먹는다. 어떤 녀석들은 나무위에서 둥지를 짓는데, 흙으로 둥지를 짓는지 나뭇가지로 둥지를 짓는지 조금씩 달라져간다. 그래도 유지보수는 하나를 알고 있다. 이 진화된 새들이 표준이라는 새로부터 가지를 쳐서 나왔기때문에 적어도 초식을 하고, 나무위에 둥지를 튼다는 사실을 말이다.
그런데 어느날 급진적 진화가 온 녀석들이 생겨났다. 부모의 특성을 완전히 버려버린 놈들이 말이다. 육식을 하며, 바닷가에서 굴을 파서 살아간다. 유지보수에게 이러한 새는 비용이 무지 높은 녀석이 되어버리고 만다. 기존에 알고 있던 부분이 전혀없기때문에 새로 연구해야하고, 기대를 하는 부분에서 전혀 엉뚱하게 행동을 하기 때문이다. 프로그래밍에서도의 표준도 이와 다를 바가 없다고 생각한다. 다양한 생태계가 발생할 수 있지만 통합되어진 하나의 기준이 있으므로서 비용을 낮추는 측면에서 말이다.
하지만 가끔은 그런 급진적인 진보가 더 이로울 수가 있다. 그 비용을 감당하고나면 더 나은 세계가 기다리고 있을지도 모르기때문이다.
- What is Flash of Unstyled Content? How do you avoid FOUC?
CSS가 적용되지 않아 순간적으로 깜빡이는 현상을 일컫는다.
방법은 간단한것 같다. CSS를 head 부분에 두어서 재빨리 적용될 수 있도록 하고,
FOUC 가 유발되는 지역을 확인해서 그 부분이 스타일이 적용된 후에 화면에 보여질 수 있도록 만드는 것이다.
- Explain what ARIA and screenreaders are, and how to make a website accessible.
좀더 검색이 필요할 것 같다. 접근 가능성에 대한 이야기인것 같은데 어떤 심오한 내용이 담겨있는 것 같다.
- Explain some of the pros and cons for CSS animations versus JavaScript animations.
- 당신의 코드의 성능을 테스트하기 위해서 사용하는 도구가 무엇입니까?
- 빌드 툴은 어떤 것을 어떻게 사용하고 있습니까?
한국 에서는 이러한 스킬들이 요구되는 것 같다. 요것도 자세하게 공부를 해봐야겠다.
-- 이태릭체의 경우는 계속 공부해야할 부분임.
댓글
댓글 쓰기